App Store opportunity data for coding agents: unmet demand, paying markets, build briefs.
Scored across 8 tools
Each tool has a distinct role: finding opportunities, generating briefs, validating markets, searching OSS, and explaining methodology. The two find tools are clearly separated by their criteria (solo feasibility vs. unmet demand), and the two brief tools are also distinct (evidence dossier vs. buildable spec). However, get_opportunity_brief references a non-existent tool name 'find_low_hanging_fruit', which could mislead an agent into expecting an additional tool or misrouting its call.
Almost all tools follow a clear verb-initial snake_case pattern: explain_method, find_solo_buildable, generate_app_brief, validate_paying_market. The only outlier is market_stats, which is a noun phrase rather than verb-object, breaking the otherwise consistent convention. Overall the naming is predictable and readable.
Eight tools cover the server's pipeline well: two discovery methods, two brief-generation stages, validation, OSS search, data coverage reporting, and method explanation. This is a well-scoped count for the domain—not too thin, not overwhelming.
The workflow from discovering opportunities through generating a buildable brief is covered, along with market validation and open-source dependency checks. Minor gaps include the stale reference to a previously named tool and no explicit refresh/update command for the data, but agents can still complete the core end-to-end workflow.
Explain the scoring formulas, weights, and the honest limitations of the data. Use when a user questions the numbers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It does add useful context by promising 'honest limitations of the data,' but it does not mention side effects, authorization needs, or what precisely happens after invocation. For a zero-parameter explanation tool this is adequate, though not rich.
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: the first states what the tool does, and the second states when to invoke it. There is no filler, repetition, or unnecessary detail.
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 no-input, no-output-schema explanation tool, the description covers the core purpose and the triggering condition. It could mention the return format or explicitly distinguish itself from a sibling, but the current information is sufficient for an agent to invoke it appropriately.
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 has zero parameters and schema description coverage is 100%, so the baseline of 4 applies. The description adds no parameter detail, but none is required because there is no input schema to elaborate on.
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 verb ('Explain') and a specific resource ('scoring formulas, weights, and the honest limitations of the data'). It also adds a distinct trigger ('when a user questions the numbers'), which clearly separates it from the market-analysis siblings such as market_stats or get_opportunity_brief.
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 a clear usage trigger: use when the user questions the numbers. It does not explicitly name alternatives or say when not to use the tool, but the stated condition is specific enough to guide selection among the listed sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find opportunities a single developer can realistically build: clear winnability plus an explicit single-user, local or offline core. Use when solo feasibility is the primary constraint.
| Name | Required | Description | Default |
|---|---|---|---|
| genre | No | Restrict to one App Store category, e.g. Productivity. | |
| limit | No | Maximum number of results to return. | |
| max_rating | No | Only include apps at or below this average rating, e.g. 4.0. | |
| storefront | No | Two-letter App Store region. The value is region identity, never a label. | us |
| max_rating_count | No | Optional ceiling to exclude unassailable giants. | |
| min_rating_count | No | Rating volume is the install proxy. On /api/lens this remains a legacy alias for the scaled value; /api/hotspots uses it literally. | |
| include_institutional | No | Include institution-locked products that a solo dev cannot win. | |
| min_rating_count_scaled | No | Pre-scaled rating volume filter. /api/lens applies max(300, floor(value / 3)); /api/paying applies max(200, floor(value / 5)). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits beyond the implicit read-only nature of a 'find' operation. There is no mention of side effects, data access, performance implications, or response format, leaving the agent without critical behavioral context.
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 zero waste. The first sentence front-loads the core purpose and criteria; the second gives a clear usage condition. 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 tool with 8 optional parameters and no output schema, the description explains the purpose and usage but does not clarify expected return values, how parameters interact, or what 'clear winnability' means in practice. It is adequate but leaves the agent to infer 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 each of the 8 parameters is already documented. The description adds no parameter-specific guidance beyond the schema, so it meets the baseline but provides no extra semantic value.
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 ('Find') and resource ('opportunities a single developer can realistically build') and defines the core criteria (clear winnability plus single-user, local or offline core). It is unambiguous and distinct from siblings like find_unmet_demand or validate_paying_market, which focus on other constraints.
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 explicitly states when to use the tool: 'Use when solo feasibility is the primary constraint.' This provides clear context, though it does not mention alternative tools or conditions when not to use it, so it lacks explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank App Store opportunities in apps that already have a large user base but whose users are clearly unhappy (unmet demand). Returns a ranked table with tier, score, rating and scale. Use this first when deciding what app to build.
| Name | Required | Description | Default |
|---|---|---|---|
| genre | No | Restrict to one App Store category, e.g. Productivity. | |
| limit | No | Maximum number of results to return. | |
| max_rating | No | Only include apps at or below this average rating, e.g. 4.0. | |
| storefront | No | Two-letter App Store region. The value is region identity, never a label. | us |
| max_rating_count | No | Optional ceiling to exclude unassailable giants. | |
| min_rating_count | No | Rating volume is the install proxy. On /api/lens this remains a legacy alias for the scaled value; /api/hotspots uses it literally. | |
| include_institutional | No | Include institution-locked products that a solo dev cannot win. | |
| min_rating_count_scaled | No | Pre-scaled rating volume filter. /api/lens applies max(300, floor(value / 3)); /api/paying applies max(200, floor(value / 5)). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool returns a 'ranked table with tier, score, rating and scale', which implies a read-only analysis operation and describes the output shape. It does not, however, mention authentication, rate limits, or any side effects, leaving some behavioral ambiguity.
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 purpose, then gives the output shape and usage guidance. 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?
The description is adequate for a first step, but with 8 parameters, no output schema, and no explanation of the ranking heuristic or endpoint-specific behavior, it leaves some gaps. An agent can call the tool, but may not understand the interplay between filters like min_rating_count_scaled and max_rating_count without deeper inspection.
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 parameters are already fully documented in the schema. The description adds little parameter-level meaning beyond the overall 'unmet demand' framing, which maps conceptually to max_rating and min_rating_count but does not explain them. 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 action and resource: 'Rank App Store opportunities' in apps with large user bases and unhappy users, and it lists the output columns. It is clear about what the tool does, but it does not explicitly differentiate itself from siblings like find_solo_buildable or get_opportunity_brief, so it falls 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?
'Use this first when deciding what app to build' gives an explicit workflow position, which is useful contextual guidance. However, it does not name alternatives or provide when-not-to-use conditions, so it lacks the exclusionary guidance required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a ready-to-build product specification for an opportunity, formatted for a specific AI coding agent (codex, claude, or cursor). Includes the wedge, the verbatim complaints to fix, verified open-source accelerators, and a verification plan.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | App Store track id. | |
| target | No | AI coding agent that will receive the brief. | codex |
| storefront | No | Two-letter App Store region. The value is region identity, never a label. | us |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output composition (wedge, complaints, accelerators, verification plan), which is useful, but it is silent on side effects, data sources, permissions, or whether the generation is deterministic.
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 no filler. The main purpose is front-loaded, and the second sentence adds valuable detail about what the brief includes. 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 3-parameter generator with no output schema, the description helpfully lists output contents, partially compensating for the missing output schema. However, it omits usage context, prerequisites, and any detail on how app_id and storefront affect the result, leaving the description adequate but not 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 baseline is 3. The description's mention of 'codex, claude, or cursor' echoes the target enum, and the schema already explains each parameter clearly. No additional semantic meaning is added.
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 deliverable ('ready-to-build product specification'), the audience ('specific AI coding agent'), and enumerates contents. It implicitly distinguishes from siblings like get_opportunity_brief by emphasizing agent-formatted, build-ready output, though it does not explicitly name sibling contrasts.
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 use this tool versus get_opportunity_brief, search_open_source_accelerators, or find_unmet_demand. The word 'ready-to-build' implies the tool belongs late in the opportunity pipeline, but no explicit when/when-not or alternative calls are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full evidence dossier for one app: score breakdown, plain-language diagnosis, complaint themes with verbatim user quotes, review provenance, and matching open-source accelerators. Use after find_low_hanging_fruit to inspect a specific candidate.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | App Store track id. | |
| storefront | No | Two-letter App Store region. The value is region identity, never a label. | us |
| include_github | No | MCP name for the REST with_github switch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It signals a read-only inspection ('dossier', 'inspect') but does not state that it is non-destructive, whether auth or quotas apply, or how the evidence is sourced/fetched.
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 well-structured sentences with no filler. The most important information (what the dossier contains) is front-loaded, followed by a crisp usage pointer.
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 no output schema, the description usefully enumerates the return contents and gives a workflow context. It omits parameter nuances and behavioral caveats, but those are either covered by the schema or are not essential for a single-app dossier 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 the schema already documents app_id, storefront, and include_github. The description adds no parameter-level detail beyond implying that app_id comes from the candidate selected earlier.
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 concrete deliverable ('Full evidence dossier for one app') and enumerates its contents (score breakdown, diagnosis, complaint themes, quotes, provenance, open-source accelerators). This clearly distinguishes it from siblings like market_stats or search_open_source_accelerators, which are narrower or market-level 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 explicitly tells the agent when to use it: 'Use after find_low_hanging_fruit to inspect a specific candidate.' It gives clear context but does not spell out exclusions or compare against every sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report local data coverage (apps, reviews, chart snapshots) and the last ingest run.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. 'Report' implies a read-only operation, and it enumerates the data categories, but it does not disclose whether results are cached, how ingestion timing is determined, or any operational characteristics such as data source or latency. This is a minimal behavioral 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 sentence that starts with the verb and packs the key output categories without filler. It is appropriately concise for a zero-parameter 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 zero-parameter reporting tool, the description covers the essential return areas, but it leaves 'local' under-specified: it never explains how the local market is determined. Since there is no output schema, a bit more detail about the returned values would improve completeness.
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 zero parameters and 100% schema coverage by definition, so there is no parameter semantics for the description to add. The baseline of 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 description uses the verb 'Report' and names concrete resources: local data coverage across apps, reviews, chart snapshots, and the last ingest run. This clearly differentiates it from siblings like explain_method or validate_paying_market, which address different concerns.
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 explicit guidance is given on when to use market_stats versus alternative tools. The description only states what it reports, so an agent must infer from the sibling names that this is the coverage/ingest-status tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find maintained, commercially reusable open-source projects for a niche, with license posture. Use to avoid rebuilding infrastructure and to check whether a dependency is safe to ship.
| Name | Required | Description | Default |
|---|---|---|---|
| genre | No | Restrict to one App Store category, e.g. Productivity. | |
| limit | No | Maximum number of results to return. | |
| theme | No | Complaint theme key, e.g. data_loss_sync, paywall_aggressive, ai_quality. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It does reveal that results include 'license posture' and implies filtering for maintenance and commercial reusability. However, it does not state whether the tool is read-only, describe the return shape, or mention any limits, pagination, or error behavior. Adequate for a simple search tool but not thorough.
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 efficient sentences with no fluff: the first gives the action and scope, the second gives concrete use cases. Information is front-loaded and every clause 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 simple tool with three optional parameters and no output schema, the description covers the core purpose and canonical usage scenarios. It omits details like exactly what 'license posture' means and how results are ordered, but these are minor given the schema already documents parameters.
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 parameters are already fully documented in the schema (genre, limit, theme). The description adds nothing about how or when to use parameters, so 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?
States a specific verb ('Find'), resource ('open-source projects'), and discriminating criteria ('maintained, commercially reusable', 'with license posture'). Also gives concrete use cases ('avoid rebuilding infrastructure', 'check whether a dependency is safe to ship'), which makes the tool's role clear and distinguishes it from sibling tools that focus on market analysis or app briefs.
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 states when to use the tool ('Use to avoid rebuilding infrastructure and to check whether a dependency is safe to ship'). It does not name alternatives or exclusions, but none of the listed siblings perform a similar function, so the missing when-not guidance is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank app categories by evidence that users already pay inside them: how many of its apps reach the store-wide Top-Grossing chart, how many charge upfront, paywall language in sampled reviews, and review depth. Call this before building to confirm a market monetises.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| storefront | No | Two-letter App Store region. The value is region identity, never a label. | us |
| min_rating_count | No | Rating volume is the install proxy. On /api/lens this remains a legacy alias for the scaled value; /api/hotspots uses it literally. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses what the tool ranks and which signals it uses, which is meaningful. However, it does not state whether the operation is read-only, what the output shape is, how many results are returned, or any limits/rate behavior. This is adequate but not rich.
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 purposeful sentences with a front-loaded action verb, a compact signal list, and a clear usage instruction. There is no filler, repetition, or unnecessary detail.
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 should clarify what the result list contains and how limit/storefront affect the ranked output. The core call context is present, but the missing return-format detail and lack of alternative routing leave a moderate 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 limit, storefront, and min_rating_count. The description adds no extra parameter-level meaning, though the signal list is consistent with the ranking purpose. 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 action ('Rank app categories'), a clear object (evidence that users already pay), and lists concrete ranking signals: Top-Grossing presence, upfront charges, paywall language, and review depth. It also states the intended pre-build validation role, distinguishing it from sibling discovery 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?
'Call this before building to confirm a market monetises' provides an explicit trigger condition. It does not explicitly say when not to use it or point to alternatives among the siblings, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_solo_buildablefind_unmet_demand2 fields changedInput schema / properties / min_rating_count / descriptionPrevious value: -"Rating volume is the install proxy. Raise it for bigger incumbents."New value: +"Rating volume is the install proxy. On /api/lens this remains a legacy alias for the scaled value; /api/hotspots uses it literally."Input schema / properties / min_rating_count_scaledAdded value: +{
+ "default": 5000,
+ "description": "Pre-scaled rating volume filter. /api/lens applies max(300, floor(value / 3)); /api/paying applies max(200, floor(value / 5)).",
+ "type": "integer"
+}validate_paying_market1 field changedInput schema / properties / min_rating_count / descriptionPrevious value: -"Rating volume is the install proxy. Raise it for bigger incumbents."New value: +"Rating volume is the install proxy. On /api/lens this remains a legacy alias for the scaled value; /api/hotspots uses it literally."explain_method1 field changedInput schema / requiredAdded value: +[]find_unmet_demand8 fields changedInput schema / properties / genre / descriptionPrevious value: -"Restrict to one category, e.g. Productivity."New value: +"Restrict to one App Store category, e.g. Productivity."Input schema / properties / include_institutional / descriptionPrevious value: -"Include institution-locked products (school portals, clinic tools) that a solo dev cannot win."New value: +"Include institution-locked products that a solo dev cannot win."Input schema / properties / limit / descriptionPrevious value: -"How many opportunities to return (max 40)."New value: +"Maximum number of results to return."Input schema / properties / limit / maximumAdded value: +200Input schema / properties / max_rating_count / defaultAdded value: +0Input schema / properties / min_rating_count / descriptionPrevious value: -"Minimum rating volume (install-scale proxy)."New value: +"Rating volume is the install proxy. Raise it for bigger incumbents."Input schema / properties / storefront / descriptionPrevious value: -"Two-letter App Store country code, e.g. us, gb, jp."New value: +"Two-letter App Store region. The value is region identity, never a label."Input schema / requiredAdded value: +[]generate_app_brief3 fields changedInput schema / properties / app_id / descriptionPrevious value: -"App Store track id of the incumbent to beat."New value: +"App Store track id."Input schema / properties / storefront / descriptionPrevious value: -"Region whose rating volume describes this app."New value: +"Two-letter App Store region. The value is region identity, never a label."Input schema / properties / target / descriptionAdded value: +"AI coding agent that will receive the brief."get_opportunity_brief3 fields changedInput schema / properties / app_id / descriptionPrevious value: -"App Store track id, as returned by find_low_hanging_fruit."New value: +"App Store track id."Input schema / properties / include_github / descriptionPrevious value: -"Also search GitHub for reusable open-source components."New value: +"MCP name for the REST with_github switch."Input schema / properties / storefront / descriptionPrevious value: -"Region whose rating volume describes this app."New value: +"Two-letter App Store region. The value is region identity, never a label."market_stats1 field changedInput schema / requiredAdded value: +[]search_open_source_accelerators4 fields changedInput schema / properties / genre / descriptionPrevious value: -"App Store category, e.g. Productivity."New value: +"Restrict to one App Store category, e.g. Productivity."Input schema / properties / limit / descriptionAdded value: +"Maximum number of results to return."Input schema / properties / limit / maximumAdded value: +200Input schema / requiredAdded value: +[]validate_paying_market6 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of results to return."Input schema / properties / limit / maximumAdded value: +200Input schema / properties / min_rating_count / defaultPrevious value: -1000New value: +5000Input schema / properties / min_rating_count / descriptionAdded value: +"Rating volume is the install proxy. Raise it for bigger incumbents."Input schema / properties / storefront / descriptionAdded value: +"Two-letter App Store region. The value is region identity, never a label."Input schema / requiredAdded value: +[]explain_methodfind_unmet_demandgenerate_app_briefget_opportunity_briefmarket_statssearch_open_source_acceleratorsvalidate_paying_marketApp Store Optimization data for AI agents: keyword ranks, scores, competitors, charts
Live App Store & Google Play data for AI agents: app discovery, ASO keywords, reviews.
App Store Optimization for AI agents: keyword ranks, suggestions, popularity, competitors, reviews
ASO analytics and App Store optimization tools for indie iOS developers and AI agents.
Add one secure layer between your agents and this server.
