Skip to main content
Glama

Kong Reviews

by com.kongreviews
OverviewDiscussionsAdmin

Recommend a stack from a description

recommend_stack
Read-only

Start here. Describe the product in plain language and get a recommended stack with costs now and at scale, in one call. Write the description as the user would: what the product does, who signs in and how, how it charges, which emails it sends, compliance or data-region needs, and expected users now and in 12 months. Example: "A booking app for yoga studios. Members sign in with Google and pay a monthly subscription. Studios get paid out. EU data. 2,000 users at launch, 20,000 within a year." Pass a PRD as the description if you have one. Numbers you pass (mau_now, mau_forecast, budget_monthly_usd, profile_id, app_type) override what is read from the text. Without a user count it assumes a new product of that app type at launch and its typical growth, and lists that in defaults_used. Before treating the plan as final, show the user the requirements it read (each quotes its sentence) and the open questions, and ask them to confirm or correct them; then call plan_stack with the corrected requirements. How to present the result: show the stack table (pick and runner-up per category, monthly cost now and at forecast) and the totals. For each price give its source's verified date, or say it is unverified seed data. Show every caveat word for word; never round, merge or drop one. Mention requirement gaps, blockers and trade-offs, and each pick's "weighed" note when a cheaper vendor lost on lock-in, setup work or seed prices. Offer the alternatives (cheapest, fewest vendors) with what each changes, its cost and its share_url. List not_planned as needed but not in the totals. Ask the questions (most expensive first) and re-plan with the answers in the argument each names (per_user, revenue_per_mau_usd, builder_profile); when the user says an assumption is right, add the question id to confirmed so it isn't asked again. On a saved stack, keep answers with update_saved_stack (answers). Link share_url so the user can open the full result on kongreviews.com. Do not add vendors or prices that are not in the result.

Input Schema

NameRequiredDescriptionDefault
seatsNoTeam members on per-seat plans. Default 1.
founderNoOptional company details used only to find startup perks.
mau_nowNoMonthly active users now or at launch.
rankingNobalanced (default): monthly cost plus a small monthly weight for lock-in, setup work before first use and unverified seed prices, so a slightly cheaper vendor that is hard to leave or slow to set up can lose. cost: price alone. simplest: fewest vendors and least setup (one vendor covering several categories wins unless the others are much cheaper). Each plan lists the other two as alternatives when their picks differ.
app_typeNoKind of app, from Product Hunt's categories: productivity, engineering_development, design_creative, finance, marketing_sales, data_analysis, platforms, no_code, product_addons, llms, ai_agents, voice_ai, social_community, health_fitness, family, lifestyle, web3, ecommerce, travel, physical_products, booking_marketplace, content_site, ios_on_device. Sets the usage profile and, when users are not given, typical users at launch and after the forecast period.
per_userNoUsage per active user a month, e.g. {"sms": 2, "file_storage_gb": 0.2, "ai_input_ktok": 30}. Replaces the profile and the filled-in defaults for those units; a plan's questions say which unit each answer sets. Units: mau, seat, request_million, bandwidth_gb, db_storage_gb, egress_gb, email, event, error_event, compute_hour, revenue_usd, transaction, ai_input_ktok, ai_output_ktok, kv_read, kv_write, ci_hour, file_storage_gb, file_egress_gb, file_write, file_read, video_min_stored, video_min_delivered, sms, job_run, search_request, search_record.
confirmedNoIds of questions whose assumption the user confirmed as right (e.g. ["region", "builder"]), so the plan stops asking them. A question answered with a figure goes in its own argument instead (per_user, revenue_per_mau_usd…).
build_toolNoThe build tool the user named, as a coding vendor id (lovable, bolt, replit, base44, v0, cursor, claude-code, github-copilot…): the plan uses it. An app builder that hosts the app and runs its database and sign-in (Lovable, Bolt, Replit, Base44) covers those, so they are not planned separately.
categoriesNoPlan these categories. Default: a build tool (an AI app builder or coding agent) plus what the description needs (a web app gets hosting, database, sign-in, email, payments and observability; an on-device app only what it names; a one-sentence idea such as a pantry tracker what that kind of app usually needs).
profile_idNoUsage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
descriptionYesPlain-language product description or PRD text.
task_intentNoWhat the user is trying to do, in a few words, e.g. "pick a stack for an MVP" or "cost section for an investor deck". No names or contact details.
mau_forecastNoMonthly active users expected at the forecast horizon.
builder_profileNoWho builds it. developer picks an AI coding agent, non_developer an app builder (and counts setup work double). Given without categories, the plan adds the build tool (coding).
forecast_monthsNo
budget_monthly_usdNo
output_destinationNoWhere the answer goes. chat (default): summary for the conversation. document: a section ready to paste into a PRD. code: adds npm packages and environment variable names for each pick.
revenue_per_mau_usdNoAverage monthly revenue per active user (for payment fees).
transactions_per_mauNoPayments per active user per month.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result. Its shape depends on the tool.
staleYes
caveatsYesShow to the user word for word.
sourcesYes
confidenceYes
assumptionsYesUsage and pricing assumptions behind the numbers.
disclosuresYesAlways includes the neutrality note: no vendor pays for a place in the answer. Link its url when you mention how Kong Reviews is paid.
generated_atYes
engine_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / build_tool
      Added value: +{
+  "description": "The build tool the user named, as a coding vendor id (lovable, bolt, replit, base44, v0, cursor, claude-code, github-copilot…): the plan uses it. An app builder that hosts the app and runs its database and sign-in (Lovable, Bolt, Replit, Base44) covers those, so they are not planned separately.",
+  "maxLength": 40,
+  "type": "string"
+}
    • addedInput schema / properties / builder_profile
      Added value: +{
+  "description": "Who builds it. developer picks an AI coding agent, non_developer an app builder (and counts setup work double). Given without categories, the plan adds the build tool (coding).",
+  "enum": [
+    "developer",
+    "non_developer",
+    "unknown"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / categories / description
      Previous value: -"Plan these categories. Default: what the description needs (a web app gets hosting, database, sign-in, email, payments and observability; an on-device app only what it names)."New value: +"Plan these categories. Default: a build tool (an AI app builder or coding agent) plus what the description needs (a web app gets hosting, database, sign-in, email, payments and observability; an on-device app only what it names; a one-sentence idea such as a pantry tracker what that kind of app usually needs)."
    • changedInput schema / properties / categories / items / enum
      Previous value: -[
-  "hosting",
-  "database",
-  "auth",
-  "email",
-  "payments",
-  "observability",
-  "ai",
-  "edge",
-  "app_store",
-  "coding"
-]New value: +[
+  "hosting",
+  "database",
+  "auth",
+  "email",
+  "payments",
+  "observability",
+  "ai",
+  "edge",
+  "app_store",
+  "coding",
+  "storage",
+  "video",
+  "sms",
+  "push",
+  "jobs",
+  "search"
+]
    • addedInput schema / properties / confirmed
      Added value: +{
+  "description": "Ids of questions whose assumption the user confirmed as right (e.g. [\"region\", \"builder\"]), so the plan stops asking them. A question answered with a figure goes in its own argument instead (per_user, revenue_per_mau_usd…).",
+  "items": {
+    "maxLength": 40,
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
    • addedInput schema / properties / per_user
      Added value: +{
+  "additionalProperties": false,
+  "description": "Usage per active user a month, e.g. {\"sms\": 2, \"file_storage_gb\": 0.2, \"ai_input_ktok\": 30}. Replaces the profile and the filled-in defaults for those units; a plan's questions say which unit each answer sets. Units: mau, seat, request_million, bandwidth_gb, db_storage_gb, egress_gb, email, event, error_event, compute_hour, revenue_usd, transaction, ai_input_ktok, ai_output_ktok, kv_read, kv_write, ci_hour, file_storage_gb, file_egress_gb, file_write, file_read, video_min_stored, video_min_delivered, sms, job_run, search_request, search_record.",
+  "properties": {
+    "ai_input_ktok": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "ai_output_ktok": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "bandwidth_gb": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "ci_hour": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "compute_hour": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "db_storage_gb": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "egress_gb": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "email": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "error_event": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "event": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "file_egress_gb": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "file_read": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "file_storage_gb": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "file_write": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "job_run": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "kv_read": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "kv_write": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "mau": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "request_million": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "revenue_usd": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "search_record": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "search_request": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "seat": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "sms": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "transaction": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "video_min_delivered": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "video_min_stored": {
+      "minimum": 0,
+      "type": "number"
+    }
+  },
+  "type": "object"
+}
    • addedInput schema / properties / ranking
      Added value: +{
+  "description": "balanced (default): monthly cost plus a small monthly weight for lock-in, setup work before first use and unverified seed prices, so a slightly cheaper vendor that is hard to leave or slow to set up can lose. cost: price alone. simplest: fewest vendors and least setup (one vendor covering several categories wins unless the others are much cheaper). Each plan lists the other two as alternatives when their picks differ.",
+  "enum": [
+    "balanced",
+    "cost",
+    "simplest"
+  ],
+  "type": "string"
+}
    • addedOutput schema / properties / disclosures / description
      Added value: +"Always includes the neutrality note: no vendor pays for a place in the answer. Link its url when you mention how Kong Reviews is paid."
  2. Changed3 schema fields changed
    • addedInput schema / properties / app_type
      Added value: +{
+  "description": "Kind of app, from Product Hunt's categories: productivity, engineering_development, design_creative, finance, marketing_sales, data_analysis, platforms, no_code, product_addons, llms, ai_agents, voice_ai, social_community, health_fitness, family, lifestyle, web3, ecommerce, travel, physical_products, booking_marketplace, content_site, ios_on_device. Sets the usage profile and, when users are not given, typical users at launch and after the forecast period.",
+  "type": "string"
+}
    • changedInput schema / properties / categories / items / enum
      Previous value: -[
-  "hosting",
-  "database",
-  "auth",
-  "email",
-  "payments",
-  "observability",
-  "ai",
-  "edge",
-  "app_store"
-]New value: +[
+  "hosting",
+  "database",
+  "auth",
+  "email",
+  "payments",
+  "observability",
+  "ai",
+  "edge",
+  "app_store",
+  "coding"
+]
    • changedInput schema / properties / profile_id / description
      Previous value: -"Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site."New value: +"Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile."
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses substantial behavior beyond the annotations: it explains assumptions, defaults_used, question flow, confirmed assumptions, caveats, alternatives, share_url, and that it must not invent vendors or prices. This is rich transparency for a read-only, open-world recommendation tool.

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

Conciseness4/5

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

The description is long and dense, but it is front-loaded with the core action and organized as a workflow. Most sentences carry actionable guidance, though the volume of presentation instructions makes it less concise than ideal.

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?

Given the tool’s complexity, 19 parameters, output schema, and rich annotations, the description is complete enough for an agent to call it correctly. It covers input guidance, assumption handling, output presentation, caveats, alternatives, and follow-up routing to plan_stack and update_saved_stack.

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

Parameters5/5

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

Although schema coverage is already high at 89%, the description adds important semantics such as which numeric arguments override text, how per_user and confirmed behave, how build_tool affects category planning, and how answers map back to specific arguments. This goes well beyond the schema’s field-level descriptions.

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?

The description opens with a clear verb and resource: 'Describe the product ... and get a recommended stack with costs now and at scale.' It also distinguishes this from the sibling plan_stack tool by saying 'Start here' and describing the workflow of confirming requirements before calling plan_stack.

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?

It explicitly tells the agent when to use this tool and how it fits with alternatives: start here, pass a PRD if available, confirm requirements, then call plan_stack with corrected requirements. It also says to use update_saved_stack for saved stacks, giving clear routing guidance.

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

All Kong Reviews toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources