Kong Reviews

Open a saved stack with current prices

get_saved_stack

Read-only

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 Schema

Name	Required	Description
`id`	Yes
`bills_month`	No	Month (YYYY-MM) for the bills comparison; default the newest with bills.
`task_intent`	No	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_destination`	No	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.

Output Schema

Name	Required	Description
`data`	Yes	The tool result. Its shape depends on the tool.
`stale`	Yes
`caveats`	Yes	Show to the user word for word.
`sources`	Yes
`confidence`	Yes
`assumptions`	Yes	Usage and pricing assumptions behind the numbers.
`disclosures`	Yes	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.
`generated_at`	Yes
`engine_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

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."

Changed1 schema field changedOct 24, 2026

addedInput schema / properties / bills_month

Added value: +{
+  "description": "Month (YYYY-MM) for the bills comparison; default the newest with bills.",
+  "maxLength": 20,
+  "type": "string"
+}

First observedOct 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only say readOnlyHint=true and openWorldHint=false, so the description adds real value by disclosing 'Needs sign-in', the confirmed/answers flow, and the fact that it re-plans on answers. It also constrains the agent ('Do not add vendors or prices that are not in the result'), which is behavior beyond the annotations. It stops short of full disclosure since rate limits, error modes and pagination are unaddressed.

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

Conciseness2/5

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

The purpose is front-loaded, but the remainder is a long run-on chain of presentation rules and caveat instructions that buries key operational facts (sign-in, id source) mid-stream. Much of the presentation guidance belongs in the output schema or a separate presentation spec, not the tool definition.

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?

With annotations and an output schema present, the description does more than required: auth requirement, sibling routing, answer persistence, and output-shaping rules. Gaps remain around the undocumented optional parameters and around whether the re-plan step mutates anything, but for a read-only call this is close to complete.

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 coverage is 75% with three of four parameters documented, so the schema already carries most parameter meaning, supporting the baseline 3. The description adds value only for id (take it from list_saved_stacks); it never mentions bills_month, task_intent, or output_destination, and confusingly names per_user, revenue_per_mau_usd and builder_profile, which are not parameters of this tool.

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 opening sentence gives a precise verb+resource+scope: re-run a saved stack or audit against today's catalogue and diff it against the saved snapshot. It is clearly distinguishable from list_saved_stacks (source of the id) and update_saved_stack (persists answers), so an agent can route without opening schemas.

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?

Explicit trigger ('when the user asks about a stack they saved, or whether prices moved') plus a concrete prerequisite ('Pass the id from list_saved_stacks') and named sibling for follow-up writes. This is genuine when/how/with-what guidance rather than a vague hint.

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

All Kong Reviews tools Inspect

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

Need Help?