Kong Reviews
Pick a tech stack from a PRD and see what it costs now and at scale, after startup perks.
| Endpoint | https://kongreviews.com/mcp (streamable-http) |
|---|---|
| Registry version | 0.2.0 |
| Now | 26 tools · grade D (58) · pin ts_36d1699df83ac85a91d379e595d38644 · protocol 2025-06-18 |
| First / last listed | 2026-10-24 23:03 UTC / 2026-10-24 23:03 UTC |
| Grade over time | 2026-10-24: D (58), 26 tools |
Is this your server? Own a server? ToolFit hosted watch re-checks it every 24 h ($0.25 per 30 days) or 6 h ($0.60) and sends you an HMAC-signed webhook when its tools or grade change: POST https://api.youraitools.co/toolfit/v1/watch. To opt out, see About & opt-out.
Tools: recommend_stack compare_architectures list_vendors list_capabilities search_directory search_showcase get_pricing estimate_cost compare_vendors check_fit project_stack find_cost_cliffs find_perks extract_requirements plan_stack evaluate_change detect_stack audit_stack diff_stack save_stack list_saved_stacks get_saved_stack update_saved_stack record_bills delete_saved_stack delete_account
recommend_stack | 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 params: description*, mau_now, mau_forecast, forecast_months, profile_id, app_type, budget_monthly_usd, categories, revenue_per_mau_usd, transactions_per_mau, seats, founder, task_intent, output_destination |
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 Ap params: description, answers, requirements, platforms, mau_now, mau_forecast, forecast_months, app_type, profile_id, budget_monthly_usd, categories, revenue_per_mau_usd, founder, task_intent, output_destination |
list_vendors | List vendors in the pricing catalogue, optionally for one category (hosting, database, auth, email, payments, observability, ai, edge, app_store, coding). params: category |
list_capabilities | List capability ids (features, compliance, regions) that requirements can reference, e.g. auth.saml_sso, region.eu, payments.merchant_of_record. params: category |
search_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 ha params: query, id, category, status, in_cost_engine, limit, offset |
search_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: { params: query, id, form, platform, category, tech, pricing, sort, limit, offset |
get_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. params: vendor_id* |
estimate_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}. params: vendor_id*, plan_id, mau, usage, required, profile_id, per_1k_mau, seats, revenue_per_mau_usd, transactions_per_mau |
compare_vendors | 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"}]}. params: category*, mau*, requirements, exclude, profile_id, per_1k_mau, seats, revenue_per_mau_usd, transactions_per_mau |
check_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. params: vendor_ids*, requirements*, mau, profile_id, per_1k_mau, seats, revenue_per_mau_usd, transactions_per_mau |
project_stack | 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"]}}. params: vendors*, start_mau*, monthly_growth, months, mau_series, apply_perks, founder, profile_id, per_1k_mau, seats, revenue_per_mau_usd, transactions_per_mau |
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}. params: vendor_id*, from_mau, to_mau, required, profile_id, per_1k_mau, seats, revenue_per_mau_usd, transactions_per_mau |
find_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"]}}. params: vendor_ids, founder |
extract_requirements | 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 params: prd_text* |
plan_stack | 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 params: categories, mau_now, app_type, mau_forecast, forecast_months, requirements, budget_monthly_usd, apply_perks, founder, exclude_vendors, architecture, answers, platforms, profile_id, per_1k_mau, seats, revenue_per_mau_usd, transactions_per_mau, task_intent, output_destination |
evaluate_change | 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.s params: category*, current*, mau_now*, monthly_growth, months, requirements, switching, switch_to, founder, profile_id, per_1k_mau, seats, revenue_per_mau_usd, transactions_per_mau |
detect_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.y params: files, text, repo, url |
audit_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) params: stack*, mau_now*, mau_forecast, profile_id, requirements, budget_monthly_usd, revenue_per_mau_usd, founder, switching, priorities, unpriced |
diff_stack | 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 params: base_files*, head_files*, mau_now, mau_forecast, profile_id, plans, requirements |
save_stack | 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 p params: name*, share_url, plan |
list_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. params: none |
get_saved_stack | 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. Needs sign-in. H params: id*, bills_month, task_intent, output_destination |
update_saved_stack | 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), and whether to email them when it changes (alerts). 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 params: id*, name, mau_now, mau_forecast, alerts, email |
record_bills | 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. 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 th params: id*, bills, csv, invoice_text, preview, remove, month |
delete_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. params: id* |
delete_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. params: confirm* |
Entries describe changes in tool definitions. They are not statements about a server, its quality or its author. The grade measures how the tool definitions fit model providers (token cost, schema compatibility, confusable names) as scored by the ToolFit engine at the time of the listing. JSON: append .json. Opt-out: how or hello@youraitools.co.