Skip to main content
Glama

find_unmet_demand

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
genreNoRestrict to one App Store category, e.g. Productivity.
limitNoMaximum number of results to return.
max_ratingNoOnly include apps at or below this average rating, e.g. 4.0.
storefrontNoTwo-letter App Store region. The value is region identity, never a label.us
max_rating_countNoOptional ceiling to exclude unassailable giants.
min_rating_countNoRating volume is the install proxy. On /api/lens this remains a legacy alias for the scaled value; /api/hotspots uses it literally.
include_institutionalNoInclude institution-locked products that a solo dev cannot win.
min_rating_count_scaledNoPre-scaled rating volume filter. /api/lens applies max(300, floor(value / 3)); /api/paying applies max(200, floor(value / 5)).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / min_rating_count / description
      Previous 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."
    • addedInput schema / properties / min_rating_count_scaled
      Added 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"
      +}
  2. Changed8 schema fields changed
    • changedInput schema / properties / genre / description
      Previous value: -"Restrict to one category, e.g. Productivity."New value: +"Restrict to one App Store category, e.g. Productivity."
    • changedInput schema / properties / include_institutional / description
      Previous 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."
    • changedInput schema / properties / limit / description
      Previous value: -"How many opportunities to return (max 40)."New value: +"Maximum number of results to return."
    • addedInput schema / properties / limit / maximum
      Added value: +200
    • addedInput schema / properties / max_rating_count / default
      Added value: +0
    • changedInput schema / properties / min_rating_count / description
      Previous value: -"Minimum rating volume (install-scale proxy)."New value: +"Rating volume is the install proxy. Raise it for bigger incumbents."
    • changedInput schema / properties / storefront / description
      Previous 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."
    • addedInput schema / required
      Added value: +[]
  3. First observed

TDQS

A3.7/5.0
Behavior3/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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources