# Kong Reviews (remote · kongreviews.com)

Pick a tech stack from a PRD and see what it costs now and at scale, after startup perks.

- Trust score: 37/100 (low)
- Change this week: 0
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `kongreviews.com`: 37/100 (this document), [markdown](https://verifymcp.io/servers/com-kongreviews-kongreviews/kongreviews.md), [page](https://verifymcp.io/servers/com-kongreviews-kongreviews/kongreviews)

## Channel facts

- Endpoint: `https://kongreviews.com/mcp`
- Transports: `streamable-http`
- Auth: `required`
- Version: `0.2.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 92/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - The endpoint enforces authorisation, advertised via RFC 9728 protected-resource metadata.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server supports Client ID Metadata Documents, the current MCP client-registration mechanism.
- **Transport & Reachability**: 0/100
  - Transport blocked by authentication: the endpoint requires auth we don't have to verify streamable-http.
- **Schema Quality & AI Usability**: 0/100
  - Schema blocked by authentication: the endpoint requires auth we don't have to read it.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 0/100
  - Tool coverage blocked by authentication: the endpoint requires auth we don't have to read its tools.
- **Tool Safety**: 0/100
  - Tool safety blocked by authentication: the endpoint requires auth we don't have to read its tools.
- **Capabilities**: 0/100
  - Capabilities blocked by authentication: the endpoint requires auth we don't have to read them.

**Unverified: 6 categories.** Categories scored 0 because we could not verify them: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.

## Install

### How do I install the Kong Reviews MCP server?

Kong Reviews is a hosted endpoint at https://kongreviews.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http com-kongreviews-kongreviews 'https://kongreviews.com/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "com-kongreviews-kongreviews": {
      "url": "https://kongreviews.com/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-kongreviews-kongreviews": {
      "type": "http",
      "url": "https://kongreviews.com/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.com-kongreviews-kongreviews]
url = "https://kongreviews.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-kongreviews-kongreviews": {
      "type": "remote",
      "url": "https://kongreviews.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-kongreviews-kongreviews --url 'https://kongreviews.com/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-kongreviews-kongreviews:
    url: "https://kongreviews.com/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "com-kongreviews-kongreviews": {
      "Transport": "http",
      "Url": "https://kongreviews.com/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-kongreviews-kongreviews -t streamable-http -u 'https://kongreviews.com/mcp'
```

### Other

```json
{
  "mcpServers": {
    "com-kongreviews-kongreviews": {
      "type": "http",
      "url": "https://kongreviews.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-27 (score 37, −27)

- [security regression] Endpoint reachability: reachable → behind authorisation
- [security regression] Stability: 0.10 → unverified
- [security regression] Tool safety: pass → unverified
- [security regression] Transport: pass → unverified
- [security improvement] Authorization: fail → pass
- [security] First check of Authorization: pass
- [functional regression] Capabilities: pass → unverified
- [functional regression] Tool coverage: 100 → unverified
- [functional regression] Schema quality: 100 → unverified

### 2026-10-26 (score 64, +1)

- [security] The server rewrote its instructions, which are the text every model session reads
- [security] Tool “evaluate_change” rewrote its description, which is the text the model reads
- [security] Tool “get_saved_stack” rewrote its description, which is the text the model reads
- [security] Tool “plan_stack” rewrote its description, which is the text the model reads
- [security] Tool “recommend_stack” rewrote its description, which is the text the model reads
- [security] Tool “search_directory” rewrote its description, which is the text the model reads
- [security] Tool “update_saved_stack” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 281 → 406
- [functional improvement] Tool coverage: 62% → 69%
- [functional] The server now declares the “prompts” capability
- [functional] New prompt “build_from_plan”
- [functional] New tool “check_build”
- [functional] New tool “get_build_pack”
- [functional] New tool “plan_migration”
- [cosmetic] “check_fit” added an optional parameter “per_user”
- [cosmetic] “compare_vendors” added an optional parameter “per_user”
- [cosmetic] “estimate_cost” added an optional parameter “per_user”
- [cosmetic] “evaluate_change” added an optional parameter “migration_features”
- [cosmetic] “evaluate_change” added an optional parameter “per_user”
- [cosmetic] “find_cost_cliffs” added an optional parameter “per_user”
- [cosmetic] “plan_stack” added an optional parameter “accounts”
- [cosmetic] “plan_stack” added an optional parameter “build_tool”
- [cosmetic] “plan_stack” added an optional parameter “builder_profile”
- [cosmetic] “plan_stack” added an optional parameter “confirmed”
- [cosmetic] “plan_stack” added an optional parameter “needs”
- [cosmetic] “plan_stack” added an optional parameter “per_user”
- [cosmetic] “plan_stack” added an optional parameter “ranking”
- [cosmetic] “project_stack” added an optional parameter “per_user”
- [cosmetic] “recommend_stack” added an optional parameter “build_tool”
- [cosmetic] “recommend_stack” added an optional parameter “builder_profile”
- [cosmetic] “recommend_stack” added an optional parameter “confirmed”
- [cosmetic] “recommend_stack” added an optional parameter “per_user”
- [cosmetic] “recommend_stack” added an optional parameter “ranking”
- [cosmetic] “search_directory” added an optional parameter “include_closed”
- [cosmetic] “update_saved_stack” added an optional parameter “answers”
- [cosmetic] “update_saved_stack” added an optional parameter “build_progress”
- [cosmetic] “update_saved_stack” added an optional parameter “migration_progress”
- [cosmetic] “update_saved_stack” added an optional parameter “unlink_repo”
- [cosmetic] “check_fit” reworded the description of “per_1k_mau”
- [cosmetic] “compare_vendors” reworded the description of “per_1k_mau”
- [cosmetic] “estimate_cost” reworded the description of “per_1k_mau”
- [cosmetic] “estimate_cost” reworded the description of “usage”
- [cosmetic] “evaluate_change” reworded the description of “per_1k_mau”
- [cosmetic] “find_cost_cliffs” reworded the description of “per_1k_mau”
- [cosmetic] “plan_stack” reworded the description of “per_1k_mau”
- [cosmetic] “project_stack” reworded the description of “per_1k_mau”
- [cosmetic] “recommend_stack” reworded the description of “categories”

### 2026-10-25 (score 63, 0)

- [security] Tool “record_bills” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 253 → 281
- [functional] New tool “compare_architectures”
- [cosmetic] “plan_stack” added an optional parameter “answers”
- [cosmetic] “plan_stack” added an optional parameter “architecture”
- [cosmetic] “plan_stack” added an optional parameter “platforms”
- [cosmetic] “record_bills” added an optional parameter “invoice_text”
- [cosmetic] “record_bills” added an optional parameter “preview”
- [cosmetic] “record_bills” reworded the description of “id”
- [cosmetic] “search_directory” reworded the description of “query”
- [cosmetic] “record_bills” made “id” optional
- [cosmetic] Tool “record_bills” changed its title: Record what a saved stack actually cost → Record what a stack or account actually cost

### 2026-10-24 (score 63, 0)

- [security] Tool “get_saved_stack” rewrote its description, which is the text the model reads
- [security] Tool “list_vendors” rewrote its description, which is the text the model reads
- [security] Tool “recommend_stack” rewrote its description, which is the text the model reads
- [security] Tool “save_stack” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 223 → 253
- [functional improvement] Stability: unverified → 0.03
- [functional] New tool “audit_stack”
- [functional] New tool “detect_stack”
- [functional] New tool “diff_stack”
- [functional] New tool “record_bills”
- [functional] New tool “search_directory”
- [functional] New tool “search_showcase”
- [functional] New tool “update_saved_stack”
- [cosmetic] “get_saved_stack” added an optional parameter “bills_month”
- [cosmetic] “plan_stack” added an optional parameter “app_type”
- [cosmetic] “recommend_stack” added an optional parameter “app_type”
- [cosmetic] “check_fit” reworded the description of “profile_id”
- [cosmetic] “compare_vendors” reworded the description of “profile_id”
- [cosmetic] “estimate_cost” reworded the description of “profile_id”
- [cosmetic] “evaluate_change” reworded the description of “profile_id”
- [cosmetic] “find_cost_cliffs” reworded the description of “profile_id”
- [cosmetic] “plan_stack” reworded the description of “mau_now”
- [cosmetic] “plan_stack” reworded the description of “profile_id”
- [cosmetic] “project_stack” reworded the description of “profile_id”
- [cosmetic] “recommend_stack” reworded the description of “profile_id”
- [cosmetic] “save_stack” reworded the description of “share_url”
- [cosmetic] “plan_stack” made “mau_now” optional

### 2026-10-23 (score 63)

First indexed and scored.

## MCP tools (29)

### `recommend_stack` (~1366 tokens)

Recommend a stack from a description

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 vendor…

Input parameters:

- `app_type` (string): 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, voic…
- `budget_monthly_usd` (number)
- `build_tool` (string): 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 databa…
- `builder_profile` (string): 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).
- `categories` (array): 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-d…
- `confirmed` (array): 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…
- `description` (string, required): Plain-language product description or PRD text.
- `forecast_months` (integer)
- `founder` (object): Optional company details used only to find startup perks.
- `mau_forecast` (number): Monthly active users expected at the forecast horizon.
- `mau_now` (number): Monthly active users now or at launch.
- `output_destination` (string): Where 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.
- `per_user` (object): 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 an…
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `ranking` (string): 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…
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `seats` (integer): Team members on per-seat plans. Default 1.
- `task_intent` (string): What 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.
- `transactions_per_mau` (number): Payments per active user per month.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `compare_architectures` (~731 tokens)

Interview, then compare architectures

Asks the questions that decide an architecture (static or dynamic, who signs in, how much data, uploads and media, background jobs and live updates, data sensitivity, threat profile, cost of downtime, who runs the servers), then rates every architecture against the answers: static site on a CDN, frontend with Supabase, serverless Next.js on Vercel, Cloudflare Workers, containers on DigitalOcean App Platform, one server, one server behind Cloudflare, Firebase, or on the phone with no server. Returns the top three with a 0-100 fit, what each service does, the monthly cost now and at forecast, strengths and concerns; the rest it considered; and the ones ruled out with the reason. Interview loop: call it with the description first; show the user the questions (each has options, why it matters, and sometimes a suggested answer read from the description); ask the unanswered ones, a few at a time, and call it again with answers. It ranks with whatever is answered, so it is fine to stop early. No model is used for the questions or the ratings. Each architecture has plan_stack_arguments and share_url for the full plan. When the user adds a requirement later, call it again with the same answers and the new description or requirements.

Input parameters:

- `answers` (object): Interview answers by question id, each an option id from compare_architectures, e.g. {"server":"dynamic","logins":"consumers","threat":"public","ops":"managed"}.
- `app_type` (string): 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, voic…
- `budget_monthly_usd` (number)
- `categories` (array): Categories to plan before the answers adjust them. Default: what the description needs.
- `description` (string): Plain-language product description or PRD text. Read for requirements (unless requirements is given) and for suggested answers.
- `forecast_months` (integer)
- `founder` (object): Optional company details used only to find startup perks.
- `mau_forecast` (number)
- `mau_now` (number)
- `output_destination` (string): Where 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.
- `platforms` (array): Where the app runs. A phone app with no web platform gets the phone questions and options.
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `requirements` (array): Requirements already confirmed; when given, the description is not read for requirements again.
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `task_intent` (string): What 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.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `list_vendors` (~50 tokens)

List vendors

List vendors in the pricing catalogue, optionally for one category (hosting, database, auth, email, payments, observability, ai, edge, app_store, coding).

Input parameters:

- `category` (string)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `list_capabilities` (~49 tokens)

List capabilities

List capability ids (features, compliance, regions) that requirements can reference, e.g. auth.saml_sso, region.eu, payments.merchant_of_record.

Input parameters:

- `category` (string)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `search_directory` (~320 tokens)

Search the service directory

Search the directory of developer services (hosting, databases, auth, email, SMS, payments, analytics, monitoring, LLM APIs, vector databases, search, CMS and more): what each provider sells, its free tier, its lowest paid price, caveats and the pricing page it came from. Wider than the cost engine: use it to find options or check a provider the other tools don't price. Entries marked candidate have no prices yet. A provider can carry availability (acquired, shutting_down) and an admin_note: say so when you mention it. Services that shut down are left out unless include_closed is true. Example: {"query":"postgres","category":"database"}.

Input parameters:

- `category` (string): Directory category id, e.g. database, email, sms, llm, vector_db. Every result lists the categories with counts.
- `id` (string): Exact provider id, e.g. "neon".
- `in_cost_engine` (boolean): true: only providers estimate_cost and plan_stack can price.
- `include_closed` (boolean): true: include services that have shut down (left out by default; an exact id always finds one).
- `limit` (integer)
- `offset` (integer)
- `query` (string): Words to match, e.g. "sms", "vector", "merchant of record", "Supabase", or a company such as "Amazon" for all its services.
- `status` (string): researched: prices read from the pricing page. candidate: listed without prices.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `search_showcase` (~290 tokens)

Search the startup showcase

Browse products startups have built and the stack each runs on: what it is, whether it is a website, a mobile app, both or a desktop app, its category and pricing, and every framework and service it uses (services link to the directory and, where priced, the cost engine). Use it to find real stacks to learn from, e.g. apps built with Supabase. Results list each filter value with counts. Example: {"tech":"supabase","form":"app"}.

Input parameters:

- `category` (string)
- `form` (string): How it ships. web: a website (maybe with a desktop app). app: a mobile app only. both: a website and a mobile app. desktop: a desktop app with no website (maybe with a mobile app).
- `id` (string): Exact product id.
- `limit` (integer)
- `offset` (integer)
- `platform` (string): Runs on this platform, whatever else it runs on.
- `pricing` (string)
- `query` (string): Words to match against names, taglines, makers and the stack, e.g. "habit tracker", "Expo".
- `sort` (string): stars: most GitHub stars first.
- `tech` (string): A tech key from facets.tech: a directory id such as "supabase", or a framework such as "next-js".

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `get_pricing` (~52 tokens)

Get vendor pricing

Structured pricing and capabilities for one vendor: every plan, base fee, metered usage, limits, unmodelled costs, lock-in notes, source URL and verification date.

Input parameters:

- `vendor_id` (string, required)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `estimate_cost` (~599 tokens)

Estimate monthly cost

Monthly cost for one vendor at a given scale. Give mau (monthly active users) and a usage profile, or exact usage numbers. Picks the cheapest plan that fits unless plan_id is set. Example: {"vendor_id":"clerk","mau":25000}.

Input parameters:

- `mau` (number)
- `per_1k_mau` (object): Override usage per 1,000 MAU. 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_kt…
- `per_user` (object): 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 an…
- `plan_id` (string)
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `required` (array): Capability ids the plan must include.
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `seats` (integer): Team members on per-seat plans. Default 1.
- `transactions_per_mau` (number): Payments per active user per month.
- `usage` (object): Exact monthly usage by unit (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_r…
- `vendor_id` (string, required)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `compare_vendors` (~477 tokens)

Compare vendors in a category

Rank vendors in one category at a given scale. Vendors meeting every must-have come first, then cheapest. Ranking is by cost and fit only. Example: {"category":"auth","mau":50000,"requirements":[{"capability":"auth.saml_sso"}]}.

Input parameters:

- `category` (string, required)
- `exclude` (array)
- `mau` (number, required)
- `per_1k_mau` (object): Override usage per 1,000 MAU. 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_kt…
- `per_user` (object): 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 an…
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `requirements` (array)
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `seats` (integer): Team members on per-seat plans. Default 1.
- `transactions_per_mau` (number): Payments per active user per month.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `check_fit` (~444 tokens)

Check requirement fit

For each vendor, show whether each requirement is met on its cheapest plan, needs a higher tier (with that tier's cost), or is missing.

Input parameters:

- `mau` (number)
- `per_1k_mau` (object): Override usage per 1,000 MAU. 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_kt…
- `per_user` (object): 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 an…
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `requirements` (array, required)
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `seats` (integer): Team members on per-seat plans. Default 1.
- `transactions_per_mau` (number): Payments per active user per month.
- `vendor_ids` (array, required)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `project_stack` (~573 tokens)

Project stack cost over time

Month-by-month cost for a whole stack as users grow, with startup perks applied if requested, plus cost cliffs (forced plan upgrades, sharp jumps, credits running out). Example: {"vendors":[{"vendor_id":"supabase"},{"vendor_id":"vercel"}],"start_mau":2000,"monthly_growth":0.15,"months":24,"apply_perks":true,"founder":{"gateways":["mercury"]}}.

Input parameters:

- `apply_perks` (boolean)
- `founder` (object): Optional company details used only to find startup perks.
- `mau_series` (array): Explicit MAU per month; overrides start_mau, monthly_growth and months.
- `monthly_growth` (number): e.g. 0.1 = 10% per month
- `months` (integer)
- `per_1k_mau` (object): Override usage per 1,000 MAU. 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_kt…
- `per_user` (object): 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 an…
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `seats` (integer): Team members on per-seat plans. Default 1.
- `start_mau` (number, required)
- `transactions_per_mau` (number): Payments per active user per month.
- `vendors` (array, required)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `find_cost_cliffs` (~475 tokens)

Find cost cliffs

Scan a range of user counts for one vendor and report where cost jumps: forced plan upgrades and points where usage charges start. Example: {"vendor_id":"clerk","from_mau":1000,"to_mau":200000}.

Input parameters:

- `from_mau` (number)
- `per_1k_mau` (object): Override usage per 1,000 MAU. 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_kt…
- `per_user` (object): 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 an…
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `required` (array)
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `seats` (integer): Team members on per-seat plans. Default 1.
- `to_mau` (number)
- `transactions_per_mau` (number): Payments per active user per month.
- `vendor_id` (string, required)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `find_perks` (~81 tokens)

Find startup perks

Startup credits for the given vendors, and whether you qualify based on your bank, incorporation provider, accelerator or funding. Example: {"vendor_ids":["supabase","posthog"],"founder":{"gateways":["mercury"]}}.

Input parameters:

- `founder` (object): Optional company details used only to find startup perks.
- `vendor_ids` (array)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `extract_requirements` (~120 tokens)

Extract requirements from a PRD

Turn PRD or spec text into structured requirements (scale, capabilities, compliance, regions, budget) for plan_stack, without planning. recommend_stack does both in one call. Each requirement quotes the sentence it came from. Show them to the user to confirm before planning. Without a model on the server it reads the PRD with keyword rules (mode "rules") and also returns the capability vocabulary and instructions: as an assistant, prefer doing the extraction yourself and use the rules result only as a starting point.

Input parameters:

- `prd_text` (string, required)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `plan_stack` (~1513 tokens)

Recommend a stack from requirements

Given confirmed requirements as capability ids, recommend a vendor per category with a runner-up, requirement fit, cost now, cost at forecast scale, year-one cost after perks, cost cliffs, trade-offs and blockers. Use recommend_stack instead when you only have a plain-language description. Example: {"mau_now":5000,"mau_forecast":20000,"profile_id":"booking_marketplace","requirements":[{"capability":"auth.google"},{"capability":"payments.merchant_of_record"}],"founder":{"gateways":["mercury"]}}. 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 parameters:

- `accounts` (object): For a business product counted in customers ("50 clinics now, 500 next year"): customers now and at the forecast, and people using it at each (default 10). Users are worked out from these when mau_no…
- `answers` (object): Interview answers by question id, each an option id from compare_architectures, e.g. {"server":"dynamic","logins":"consumers","threat":"public","ops":"managed"}.
- `app_type` (string): 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, voic…
- `apply_perks` (boolean)
- `architecture` (string): Plan with only this architecture's vendors, from compare_architectures (e.g. serverless_nextjs, cloudflare_edge, vps_cloudflare).
- `budget_monthly_usd` (number)
- `build_tool` (string): 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 databa…
- `builder_profile` (string): 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).
- `categories` (array)
- `confirmed` (array): 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…
- `exclude_vendors` (array)
- `forecast_months` (integer)
- `founder` (object): Optional company details used only to find startup perks.
- `mau_forecast` (number)
- `mau_now` (number): Monthly active users now. Without it, a new product of the app type at launch.
- `needs` (array): Needs the plan should list even though they are not priced (directory category ids such as maps, vector_db, speech), from recommend_stack's requirements_read.needs.
- `output_destination` (string): Where 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.
- `per_1k_mau` (object): Override usage per 1,000 MAU. 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_kt…
- `per_user` (object): 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 an…
- `platforms` (array): Where the app runs; with architecture, a phone-only app leaves out web hosting.
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `ranking` (string): 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…
- `requirements` (array)
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `seats` (integer): Team members on per-seat plans. Default 1.
- `task_intent` (string): What 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.
- `transactions_per_mau` (number): Payments per active user per month.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `evaluate_change` (~712 tokens)

Stay, optimise or switch

When something changes (bill too high, growth, a missing feature such as SSO, a renewal), compare staying on the current plan, optimising with the same vendor, and switching vendor, including one-off switching cost and the month switching pays off. Example: {"category":"auth","current":{"vendor_id":"clerk","plan_id":"pro"},"mau_now":11000,"monthly_growth":0.18,"requirements":[{"capability":"auth.saml_sso"}]}. When a migration playbook covers the move (Netlify to DigitalOcean App Platform so far) and switching.hours is left out, the switching cost uses its effort range, not a flat 40 hours; plan_migration gives the full plan. How to present the result: show stay, optimise and switch side by side with cumulative cost at each month given, the break-even month and any problems; show every caveat word for word.

Input parameters:

- `category` (string, required)
- `current` (object, required)
- `founder` (object): Optional company details used only to find startup perks.
- `mau_now` (number, required)
- `migration_features` (array): Features of the current host the app uses (feature ids from plan_migration or detect_stack's netlify_features), so a migration playbook prices the work. Leave switching.hours out to use them.
- `monthly_growth` (number)
- `months` (integer)
- `per_1k_mau` (object): Override usage per 1,000 MAU. 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_kt…
- `per_user` (object): 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 an…
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `requirements` (array)
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `seats` (integer): Team members on per-seat plans. Default 1.
- `switch_to` (string): Evaluate a specific vendor instead of the best-ranked alternative.
- `switching` (object)
- `transactions_per_mau` (number): Payments per active user per month.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `detect_stack` (~247 tokens)

Detect an existing app's stack

Work out which services an existing app runs on, from its files, a public GitHub repo, or its live website. From an AI coding app, read the project yourself and pass the files that say the most: package.json (or requirements.txt, pyproject.toml, Gemfile, go.mod, pubspec.yaml, Podfile), .env.example (names only, never secret values), and deploy configs (vercel.json, netlify.toml, fly.toml, render.yaml, .do/app.yaml, wrangler.toml, firebase.json, Dockerfile). Returns each catalogue vendor found with its evidence and confidence, services the catalogue can't price yet, frameworks and platforms. Rules only; nothing is stored. Then call audit_stack with the services (and their plans, if the user knows them).

Input parameters:

- `files` (array)
- `repo` (string): Public GitHub repo: owner/name or its github.com address.
- `text` (string): Pasted text, e.g. a package.json or a list of services, when there are no file names.
- `url` (string): The live website, to read its hosting headers and the scripts it loads.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `audit_stack` (~384 tokens)

Audit an existing stack

Assess the stack an existing app runs on and recommend what to do. For each service: its plan, cost now and in 12 months, must-haves it lacks, cost jumps in the next year, lock-in, and a verdict (keep, watch, optimise, switch or fix) with savings, one-off moving cost and the month a switch pays off. Then a scorecard (cost, requirements, ready to scale, lock-in; A to F, weighted by priorities 0-3) and recommendations ranked by what the user cares about. Categories the requirements need but nothing covers are suggested too. Use the vendor ids from detect_stack; pass plan_id when the user knows their plan (otherwise the cheapest that serves today's users is assumed and said so). How to present: lead with the summary and overall grade, then the ranked recommendations with savings or added cost, then the scorecard; show every caveat and assumption word for word.

Input parameters:

- `budget_monthly_usd` (number)
- `founder` (object): Optional company details used only to find startup perks.
- `mau_forecast` (number): Monthly active users expected in 12 months.
- `mau_now` (number, required)
- `priorities` (object): How much each criterion matters, 0 (not at all) to 3 (most). Defaults: cost 3, requirements 3, scale 2, lock_in 1.
- `profile_id` (string): Usage profile, e.g. b2b_saas, consumer_app, booking_marketplace, content_site, ios_on_device.
- `requirements` (array)
- `revenue_per_mau_usd` (number)
- `stack` (array, required)
- `switching` (object)
- `unpriced` (array): Services detect_stack found that the catalogue can't price (its "unknown" list).

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `plan_migration` (~928 tokens)

Plan a move to another host

Plan moving an existing app from one host to another (playbooks so far: netlify → digitalocean-app-platform). Reads the repo (files, pasted text or a GitHub repo, as detect_stack does) for the features the app uses on the current host. Returns, in this order: the verdict (monthly cost before and after, one-off hours low to high, the month the move pays off, and whether staying is cheaper; staying is a valid answer), the features (those with no equivalent or that need another service first, each with its effort, risk, steps and sources), what to check in the current host's dashboard because the repo can't show it, a draft .do/app.yaml, and a cutover runbook that keeps the old site live until the new one is proven. Pass features the person confirms from their dashboard (e.g. netlify-dns, forms, deploy-previews) in features. Nothing is deployed or stored; the person deploys the spec themselves. How to present: lead with the verdict and say plainly when staying is cheaper; then the features with no equivalent or needing a service; then the rest, the checks, the spec and the runbook. Show every caveat word for word.

Input parameters:

- `branch` (string)
- `current_plan_id` (string): The current host plan, if known; otherwise the cheapest that serves today's users is assumed.
- `domain` (string): The site's domain, for the draft spec.
- `features` (array): Feature ids the person confirms the app uses, including what only the dashboard shows (netlify-dns, forms, deploy-previews, custom-domain).
- `files` (array): netlify.toml, _redirects, _headers, package.json, .env.example (names only), files in netlify/functions and netlify/edge-functions, and pages with forms.
- `from` (string): Current host vendor id. Default netlify.
- `hourly_rate_usd` (number): What an hour of work costs. Default $100.
- `id` (string): A saved audit id (list_saved_stacks; needs sign-in): uses its users and plan, and shows the steps ticked so far.
- `mau_now` (number): Monthly active users today. Default 1,000, and the result says it was assumed.
- `monthly_growth` (number)
- `months` (integer)
- `per_1k_mau` (object): Override usage per 1,000 MAU. 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_kt…
- `per_user` (object): 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 an…
- `profile_id` (string): Usage profile: b2b_saas (default), consumer_app, booking_marketplace, content_site, ios_on_device. Defaults to the app type's profile.
- `repo` (string): GitHub repo: owner/name or its github.com address.
- `revenue_per_mau_usd` (number): Average monthly revenue per active user (for payment fees).
- `seats` (integer): Team members on per-seat plans. Default 1.
- `text` (string)
- `to` (string): Target host vendor id. Default digitalocean-app-platform.
- `transactions_per_mau` (number): Payments per active user per month.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `diff_stack` (~211 tokens)

Price a code change (pull request)

What a code change does to an app's bill: pass the files before (base_files) and after (head_files) the change, such as package.json, requirements.txt, .env.example (names only) and deploy configs. Returns the services added and removed, each priced now and in 12 months at the given users, with cheaper options and cost jumps, the change in monthly cost, and comment_markdown ready to post on a pull request. Use it before adding a paid service or SDK, or to review a pull request. Rules only; nothing is stored.

Input parameters:

- `base_files` (array, required)
- `head_files` (array, required)
- `mau_forecast` (number): Users expected in 12 months.
- `mau_now` (number): Monthly active users today. Default 1,000, and the comment says it was assumed.
- `plans` (array): Plans the app is on, when known.
- `profile_id` (string)
- `requirements` (array)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `save_stack` (~182 tokens)

Save a stack to your account

Save a recommended stack, or an audit of an existing app, to the signed-in user's Kong Reviews account so it can be reopened later and compared with current prices. Pass the share_url from recommend_stack, plan_stack or audit_stack (preferred) or the plan_stack arguments, plus a short name such as "Yoga booking MVP". Afterwards, offer update_saved_stack with alerts: true so they are emailed when prices or cost jumps change it. Needs sign-in: if the user isn't signed in, the app will ask them to connect their Kong Reviews account. Only save when the user asks to keep or save a stack.

Input parameters:

- `name` (string, required): Short name the user will recognise.
- `plan` (object): plan_stack arguments, if there is no share_url.
- `share_url` (string): share_url returned by recommend_stack, plan_stack or audit_stack.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `list_saved_stacks` (~97 tokens)

List your saved stacks

List the stacks the signed-in user saved, newest first, with their monthly cost when saved and a link to each. Use it when the user mentions "my stacks", "the stack I saved" or a saved stack by name; then call get_saved_stack for one of them. Needs sign-in. How to present: a short table of name, saved date and monthly cost when saved, each name linked to its share_url.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `get_saved_stack` (~471 tokens)

Open a saved stack with current prices

Re-run a saved stack or audit with today's catalogue and compare it with when it was saved: monthly cost then and now, picks (or plans) that changed, vendors whose pricing changed and, for audits, the grade; and any bills recorded with record_bills next to the estimate. Use it when the user asks about a stack they saved, or whether prices moved. Pass the id from list_saved_stacks. Its questions are what is still assumed; keep the user's answers on the stack with update_saved_stack (answers). Needs sign-in. 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 parameters:

- `bills_month` (string): Month (YYYY-MM) for the bills comparison; default the newest with bills.
- `id` (string, required)
- `output_destination` (string): Where 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.
- `task_intent` (string): What 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.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `get_build_pack` (~297 tokens)

Get the build pack for a planned stack

Everything needed to start building a planned stack: the decisions (each service, what it covers, the runner-up, cost now and at forecast), setup steps in order (domain, hosting, database, sign-in, email, payments, monitoring), the variable names as .env.example, KONG.md (a brief for the AI assistant: the stack, rules, cost cliffs, setup order, and what "done" means), an acceptance checklist and cost guardrails. For a plan built with an app builder (builder_profile non_developer), KONG.md is one prompt to paste into the builder instead. Pass the share_url of a plan (no sign-in needed) or the id of a saved plan (needs sign-in). Write KONG.md and .env.example into the project root, then follow the steps with the user. Values never pass through Kong Reviews: only variable names.

Input parameters:

- `framework` (string): What the app is built with: nextjs (default), remix (Remix or React Router), sveltekit, astro, expo (React Native) or node (Express). Picks each service's package, variable names and guide for it. Re…
- `id` (string): A saved plan id from list_saved_stacks (needs sign-in).
- `share_url` (string): A plan link from plan_stack, recommend_stack or kongreviews.com.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `check_build` (~221 tokens)

Check a repo against its saved plan

Link the GitHub repo a saved plan is being built in, and check it: detect_stack reads the repo and each planned service is marked found or not found yet (normal while building), services the repo uses that the plan doesn't are listed as drift, and when every planned service is found the plan is marked built. Pass id (a saved plan from list_saved_stacks) and repo the first time; after that, id alone checks the linked repo again. Private repos need the Kong Reviews GitHub App on that repo. How to present: say whether it is built; list what is not found yet as the next setup steps (from get_build_pack); for each drift service, ask the user whether to keep it (price it with diff_stack, or re-plan) or take it out of the code. Needs sign-in.

Input parameters:

- `id` (string, required): A saved plan id from list_saved_stacks.
- `repo` (string): GitHub repo: owner/name or its github.com address. Links it to the plan, replacing any linked before.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `update_saved_stack` (~425 tokens)

Update a saved stack: users, name or alerts

Change one of the signed-in user's saved stacks or audits: its name, how many users it has now (mau_now) or expects (mau_forecast), whether to email them when it changes (alerts), which build-pack steps are done (build_progress, for plans) and which steps of a host move are done (migration_progress, for audits). With alerts on, Kong Reviews checks it every day and emails when a vendor's price change moves its monthly cost, when a cost jump or a startup credit running out is about 45 days away, and once a month to ask for the current user count. Alerts need a confirmed email: pass email to send the confirmation link (GitHub sign-in shares no email). Updating users re-prices it and makes today the start of its projection. Needs sign-in.

Input parameters:

- `alerts` (boolean): Email the user when prices, cost jumps or credits change this stack.
- `answers` (object): Answers to the plan's questions (from get_saved_stack), kept with the stack so a re-plan doesn't ask again. Plans only. Re-prices the stack.
- `build_progress` (object): Tick build-pack steps done (true) or not done (false), by step id from get_build_pack: domain or the step's category (hosting, database, auth…). Plans only.
- `email` (string): Where alerts go. A confirmation link is sent first; only ask for it when the user wants alerts.
- `id` (string, required)
- `mau_forecast` (number): Users expected at the end of the forecast (12 months for audits).
- `mau_now` (number): Monthly active users today.
- `migration_progress` (object): Tick a host move's features and cutover steps done (true) or not done (false), by id from plan_migration (e.g. forms, redirects, lower-ttl, switch). Audits only.
- `name` (string)
- `unlink_repo` (boolean): Forget the repo linked with check_build, and its last check.

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `record_bills` (~435 tokens)

Record what a stack or account actually cost

Record what the user actually paid each service in a month, on one of their saved stacks or audits, and compare it with the estimate at the users it was saved with. Without id, the bills are kept on the account, not on a stack (for someone who has not saved one): they are recorded and listed, with no estimate to compare, and can be moved onto a stack later on the Billing page. Pass bills (month as YYYY-MM, the service as vendor_id or name as on the invoice, amount_usd), or csv: a billing export with columns for month or date, service or vendor, and amount, or invoice_text: an invoice's text as pasted from the PDF or email (the service, month and total are read from it, each with the invoice line it came from; preview: true reads it without saving, so the user can check it first). A bill replaces any earlier one for the same service and month; remove deletes a month (or one service in it). Returns, per service, the estimate, the bill and the difference, flagging bills more than 20% (and $5) over or under. With alerts on, a bill well over its estimate is emailed too. Needs sign-in. How to present: a table of service, estimate, billed and difference; then say what could explain the biggest gap (more users or usage than given, a plan above the one assumed, add-ons the catalogue does not price) and offer update_saved_stack with the real user count.

Input parameters:

- `bills` (array)
- `csv` (string): A CSV billing export: a header row, then one row per charge.
- `id` (string): The saved stack or audit. Leave out to keep the bills on the account.
- `invoice_text` (string): One invoice's text, copied from the PDF or the email.
- `month` (string): Which month to compare. Default: the newest with bills.
- `preview` (boolean): With invoice_text: read it and show what was found, without saving.
- `remove` (object)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `delete_saved_stack` (~52 tokens)

Delete a saved stack

Permanently delete one of the signed-in user's saved stacks by id. Only call it when the user explicitly asks to delete that stack; confirm the name first. Needs sign-in.

Input parameters:

- `id` (string, required)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

### `delete_account` (~76 tokens)

Delete your Kong Reviews account

Permanently delete the signed-in user's Kong Reviews account: their GitHub sign-in link and every saved stack. This cannot be undone. Only call it when the user explicitly asks to delete their account, after telling them what will be removed; pass confirm exactly as "delete my account". Needs sign-in.

Input parameters:

- `confirm` (string, required)

Output parameters:

- `assumptions` (array): Usage and pricing assumptions behind the numbers.
- `caveats` (array): Show to the user word for word.
- `confidence` (string)
- `data`: The tool result. Its shape depends on the tool.
- `disclosures` (array): 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.
- `engine_version` (string)
- `generated_at` (string)
- `sources` (array)
- `stale` (boolean)

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-kongreviews-kongreviews/kongreviews#diagnostics

## Score history

- 2026-11-05: 37
- 2026-11-04: 37
- 2026-11-03: 37
- 2026-11-02: 37
- 2026-11-01: 37
- 2026-10-31: 37
- 2026-10-30: 37
- 2026-10-29: 37
- 2026-10-28: 37
- 2026-10-27: 37
- 2026-10-26: 64
- 2026-10-25: 63
- 2026-10-24: 63
- 2026-10-23: 63

## Common questions

### What is the Kong Reviews MCP server?

Kong Reviews is an MCP server listed in the public MCP registry as com.kongreviews/kongreviews. Pick a tech stack from a PRD and see what it costs now and at scale, after startup perks. This page covers its hosted endpoint (https://kongreviews.com/mcp).

### Is the Kong Reviews MCP server safe to use?

Kong Reviews scores 37 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Kong Reviews MCP server expose?

Kong Reviews exposes 29 tools: recommend_stack, compare_architectures, list_vendors, list_capabilities, search_directory, and 24 more. Their descriptions and schemas cost roughly 11,878 tokens of context every time the server is loaded.

### Does the Kong Reviews MCP server require authentication?

Yes. Kong Reviews asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.

### Is the Kong Reviews MCP server still maintained?

Kong Reviews is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://kongreviews.com/mcp
- Website: https://kongreviews.com/
- Changelog RSS feed: https://verifymcp.io/servers/com-kongreviews-kongreviews/kongreviews.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-kongreviews-kongreviews/kongreviews.json
- HTML version of this page: https://verifymcp.io/servers/com-kongreviews-kongreviews/kongreviews
