Skip to main content
Glama

Kong Reviews

by com.kongreviews
OverviewDiscussionsAdmin

Audit an existing stack

audit_stack
Read-only

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 Schema

NameRequiredDescriptionDefault
stackYes
founderNoOptional company details used only to find startup perks.
mau_nowYes
unpricedNoServices detect_stack found that the catalogue can't price (its "unknown" list).
switchingNo
prioritiesNoHow much each criterion matters, 0 (not at all) to 3 (most). Defaults: cost 3, requirements 3, scale 2, lock_in 1.
profile_idNoUsage profile, e.g. b2b_saas, consumer_app, booking_marketplace, content_site, ios_on_device.
mau_forecastNoMonthly active users expected in 12 months.
requirementsNo
budget_monthly_usdNo
revenue_per_mau_usdNo

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. Changed3 schema fields changed
    • changedInput schema / properties / requirements / items / 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"
+]
    • changedInput schema / properties / stack / items / 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"
+]
    • 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. Changed2 schema fields changed
    • changedInput schema / properties / requirements / items / 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 / stack / items / 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"
+]
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the readOnlyHint=true and openWorldHint=false annotations. It explains per-service outputs, assumptions when plan_id is missing, verdict categories, savings, moving costs, payback month, scorecard weighting, and presentation instructions including showing caveats verbatim.

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 front-loaded with a clear purpose sentence and then adds output, usage, and presentation details. It is dense and long, but nearly every sentence contributes to calling or presenting the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 11-parameter analysis tool with an output schema, the description is behaviorally rich and explains assumptions and presentation. It is not fully complete on input parameter semantics, but the output schema and existing schema descriptions reduce that burden.

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

Parameters3/5

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

Schema description coverage is 45% across 11 parameters, so the description must compensate. It adds useful semantics for plan_id fallback, vendor_id sourcing from detect_stack, and priorities weighting, but leaves many parameters such as mau_now, switching, budget_monthly_usd, revenue_per_mau_usd, profile_id, and unpriced largely unexplained.

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 uses a specific verb and resource: assess an existing app's stack and recommend actions. It clearly distinguishes the tool from detect_stack by saying to use vendor ids from detect_stack, and it names the concrete outputs (verdicts, scorecard, ranked recommendations).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for use: existing apps, after detect_stack, with optional plan_id when the user knows their plan. It does not explicitly state when not to use it versus siblings like evaluate_change or diff_stack, but the workflow guidance is strong.

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