Stackcut

Name: Stackcut
Author: Stackcut

Server Details

Cancel or cut any subscription: exit steps, cheaper plans, alternatives and the cheapest stack.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 27 days
Last Tested: 2026-10-21 08:44
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: Stackcut/stackcut-plugin
GitHub Stars: 0

TDQS

A3.6/5.0

Scored 2026-10-17 11:40 across 24 tools

Disambiguation3/5

Several clusters overlap: the four report_* tools (report_outcome, report_exit_outcome, report_action_outcome, report_guide_feedback) all log outcomes of user actions, with report_outcome vs report_exit_outcome being especially close (both anonymous counters). Audit flow tools (start_audit, audit_stack, get_usage_questions) and catalog tools (search_recipes/get_recipe, search_workflow_recipes/get_workflow_recipe, search_exits/get_exit_plan) are mostly saved by descriptions that explicitly cross-reference each other. Boundaries exist but are thin in the reporting and audit-entry areas.

Naming Consistency4/5

Nearly every tool follows a clean verb_noun snake_case pattern (audit_stack, get_exit_plan, search_recipes, report_outcome, list_categories). The only clear deviation is 'leaderboard', which is a bare noun with no verb and no prefix matching any family. Minor inconsistency but overall highly predictable.

Tool Count3/5

24 tools is at the heavy end (16-25 range), and the domain genuinely spans audit, vendor choice, replacement, cancellation, negotiation, build, search and reporting, so breadth is somewhat justified. However, four separate reporting tools plus multiple near-duplicate search/get pairs push it past what's needed, suggesting consolidation is possible.

Completeness4/5

The surface covers the full lifecycle implied by the domain: discover (list_categories, leaderboard, search_discoveries), audit (start_audit, audit_stack), choose/plan (choose_stack, plan_stack_from_spec), replace (search_recipes, get_recipe, get_build_packet), cancel/negotiate (get_exit_plan, prepare_negotiation), and report outcomes. Coverage is broad with only minor gaps, such as no explicit update/refresh of a saved plan beyond get_my_plan.

Available Tools

24 tools

audit_stackAudit a stack (code + billing)A

Read-onlyIdempotent

Inspect

Use when the user wants their stack checked as a whole: several subscriptions, the paid services in a codebase, or a portfolio of products ('audit what we pay for', 'what can we cut?'). One line per service with vendor, plan, what they pay, seats, the features they use and usage (or evidence strings); add project for a portfolio and account for a shared bill. Per service: status (eligible = a cheaper path checked end to end; needs_info = likely cheaper but a check is open, so ask its questions; keep; no_recipe), the best path, right_size, overlaps, and levers that are not counted as savings. Totals keep prices the user confirmed apart from modeled list prices. If facts are missing, start_audit says which ones matter first. Send vendor names, feature names, numbers and prices only: never source code, secrets or raw invoices. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`decision`	No	consolidate: overlaps on every job each tool does
`services`	Yes
`limit_paths`	No
`active_users`	No	People or accounts active in the last 30 days (0 = unused: cleanup levers and sanity checks)
`revenue_usd_per_month`	No	The product's revenue per month (context for sanity checks: no revenue, cost per user, fees vs revenue; never a cap)

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds substantial behavior: output shape (one line per service with vendor/plan/pay/seats/features/usage), per-service status semantics (eligible, needs_info, keep, no_recipe), how totals separate confirmed from modeled prices, and explicit data-handling/retention rules (never source code, secrets or raw invoices; account keys hashed; never IP addresses). This is unusually rich disclosure beyond the annotations.

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

Conciseness3/5

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

The trigger is correctly front-loaded, but the body collapses output format, status vocabulary, totals logic, sending constraints and a long data-retention/privacy clause into one dense block without structure. Much is valuable, yet the privacy paragraph is verbose and buries the operational guidance an agent needs.

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, no-output-schema tool the description covers a lot: return format, statuses, totals semantics, and hard constraints on what may be sent. It is nearly complete, though a few inputs (limit_paths, decision values) are left entirely to the schema.

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

Parameters4/5

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

Schema coverage is only 60%, so the description must carry weight, and it does for the services array: it explains what a line contains, how project enables portfolio audits, and how a shared bill/account should be supplied. It does not explain limit_paths or restate the decision enum meanings, leaving some parameters to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('stack checked as a whole') plus the concrete scopes it covers: several subscriptions, paid services in a codebase, or a portfolio of products, with example utterances. It distinguishes itself from start_audit ('If facts are missing, start_audit...'), but it does not clearly separate itself from choose_stack or find_alternatives, which a sibling-aware agent would also want.

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?

Gives clear when-to-use triggers ('audit what we pay for', 'what can we cut?') and routes the missing-facts case to start_audit. It never states when NOT to use it or contrasts explicitly with the other audit/comparison siblings, so it stops short of full when/when-not/alternatives guidance.

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

choose_stackChoose the most cost-effective stackA

Read-onlyIdempotent

Inspect

Use when the user is picking vendors for something they're building: 'cheapest database for 20k users', 'Resend or Postmark at 60,000 emails a month?', 'what will auth cost at 10k MAU?'. Give each job with its volumes and must-have features; every tier of every indexed vendor is priced at those volumes and the cheapest valid tier wins. A pick 'fits' only when every volume is within published caps or priced overage, no published limit is broken, each must-have is included in that plan or priced as its add-on, and the price was checked within 120 days; anything else comes back as a check or a question. total keeps proven, estimated and unpriced jobs apart. Pass scales (MAU) for cost curves and break-evens; with no MAU elsewhere, the smallest scale is the MAU priced. budget_monthly_usd tests a budget. For a whole product brief, use plan_stack_from_spec. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`needs`	Yes
`prefer`	No	managed leaves out self-hosted options	cheapest
`scales`	No	Price the stack at several scales, e.g. [1000, 20000, 200000] MAU (scale_by mau) or [1, 10, 100] (scale_by multiplier): per-job cost curve, tier changes and break-even points between options
`project`	No	What is being built. Volumes written here ('1,200,000 preview images/mo', '20k MAU') are used and echoed as assumptions. Say 'personal' or 'hobby' if it is non-commercial; otherwise plans that forbid commercial use (e.g. Vercel Hobby) are blocked.
`scale_by`	No	mau: scales are monthly active users (per_user volumes × MAU; other monthly volumes and sizes grow in proportion to the MAU they were given at); multiplier: every monthly volume and size is multiplied	mau
`limit_per_job`	No
`unit_economics`	No	Revenue model for gross margin per scale: price_usd with conversion_rate, or revenue_per_mau
`budget_monthly_usd`	No

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description still adds substantial context beyond them: the exact 'fit' criteria, what comes back as a check versus a question, how 'total' separates proven/estimated/unpriced jobs, and a detailed data-handling disclosure (arguments stored, account keys one-way hashed, never IP addresses, results summarized, exit tools log counts not contents). This is unusually rich transparency for a read-only tool.

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

Conciseness4/5

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

Front-loaded with the usage trigger, then the pricing mechanism, then result semantics, parameter hints, the sibling route and data handling. Sentences are dense and mostly earn their place, though the long parenthetical data-handling clause is heavier than the surrounding content and could be trimmed.

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 tool with nested objects and no output schema, the description covers the essentials an agent needs: what inputs to supply, how results are classified (fit/check/question), and how totals are partitioned. Gaps remain around limit_per_job and unit_economics output, but nothing critical to a correct call is missing.

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 63% and the schema itself documents most units, features and unit_economics fields, so the baseline is 3. The description adds genuine meaning for 'scales' (smallest scale becomes the priced MAU when no MAU is given) and briefly for 'budget_monthly_usd', but says nothing about limit_per_job, prefer, peak_volume or unit_economics, leaving several parameters to the schema alone.

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?

States a specific verb+resource+goal ('choosing vendors ... the cheapest valid tier wins') and anchors it with three concrete user-utterance examples ('cheapest database for 20k users', 'Resend or Postmark at 60,000 emails a month?'). It also explicitly distinguishes itself from the sibling 'plan_stack_from_spec', so an agent can route between them 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?

Gives a clear when-to-use trigger ('picking vendors for something they're building'), an explicit when-not with the alternative named ('For a whole product brief, use plan_stack_from_spec'), and points to 'scales' for cost curves/break-evens and 'budget_monthly_usd' for budget checks. Alternative routing is fully spelled out.

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

find_alternativesFind alternatives for a subscriptionA

Read-onlyIdempotent

Inspect

Use when the user names one product they pay for and asks for something cheaper, whether it's worth it, or what to switch to: 'cheaper than Typeform?', 'is Semrush worth $139 a month for us?', 'we pay $90 for SendGrid'. Pass what they pay (monthly_spend_usd), seats, the features they use and their usage (usage, or evidence such as '40,000 emails/mo') so each plan's caps can be checked. Returns ranked paths re-costed at their price, including a cheaper plan of the same vendor (right_size). A path with fit 'fits' passed every check; a 'check' path is a candidate with open checks, so ask its questions before recommending it. status, why and questions say what is still missing. Savings are modeled from public list prices. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`plan`	No	Their plan, e.g. 'Essential' (else read from the vendor name)
`limit`	No
`seats`	No	Paid seats; per-seat prices on both sides scale with it
`usage`	No	Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, identified_events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, boards, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month, hosts, tickets_per_month (MAU is accepted for mau). Example: {"emails_per_month": 40000, "domains": 4, "db_gb": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number.
`vendor`	Yes	Product name as on the invoice, e.g. 'Typeform', 'Slack Pro', 'HubSpot Sales Hub Starter'
`billing`	No	Billing evidence: scope (dedicated, shared or unknown), account_id (a non-secret alias; the account key), allocated_monthly_usd (attribution only, never a saving), avoidable_monthly_usd with avoidability_confirmed (what leaving actually removes from the bill; 0 is valid), commitment_months_remaining (non-refundable months left; 0 only when cancellable now) and source (a reference, no private contents). With billing, a path is eligible only once the avoidable amount, scope, commitment and source are all given
`evidence`	No	Usage facts in words, read best effort: 'db 1.5 GB', '40,000 emails/mo', '37 domains', '3,000 MAU', 'shared by 40 projects'
`confirmed`	No	true when the user confirmed they pay for this (with plan: its list price counts as confirmed spend). Scanner-only lines are unconfirmed
`last_active`	No	When this resource (project, app, account) was last used: an ISO date ('2026-03-10'), 'never', or '5 months ago'. 90+ days idle or never used gets a cleanup lever
`shared_with`	No	How many products share this bill (one account, org or team), when only this product is audited: moving one product off it saves only what it adds to the bill, never the whole bill. monthly_spend_usd is then the whole account's bill
`active_users`	No	People or accounts active in the last 30 days (0 = unused: cleanup levers and sanity checks)
`features_used`	No	Features they actually use; sizes and counts ('4,000 contacts', 'videos over 5 minutes') are read as usage
`monthly_spend_usd`	No	What they pay per month today, all seats (replaces the modeled baseline)
`revenue_usd_per_month`	No	The product's revenue per month (context for sanity checks: no revenue, cost per user, fees vs revenue; never a cap)
`replacement_validation`	No	A replacement path the user checked themselves: its current price, capacity, burst limits and paid add-ons against their usage. It answers that path's capacity checks (never its must-haves) and ranks it first

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: savings are 'modeled from public list prices', results are summarized, and there is an explicit data-handling disclosure (what arguments are stored, that account keys are hashed, billing/validation sources are excluded, and no personal data should be sent). The 'fits' vs 'check' fit semantics and the instruction to ask a check path's questions before recommending it are exactly the behavioral detail annotations cannot carry.

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?

Front-loaded with the usage trigger and return semantics, and every sentence is doing work. The privacy paragraph is long, but for a tool that persists call arguments it earns its place; overall it is dense rather than padded.

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

Completeness5/5

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

There is no output schema, so the description must explain returns — and it does (ranked re-costed paths, right_size, fit values, status/why/questions). Combined with the pricing caveat, data policy, and parameter sourcing advice, it is complete for a 15-parameter, nested-object tool.

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

Parameters4/5

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

Schema coverage is already 93%, so the schema does most of the work. The description still adds targeted guidance — pass monthly_spend_usd, seats, features used, and usage/evidence 'so each plan's caps can be checked' — which explains why these inputs matter and how to source them (evidence strings, get_usage_questions).

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?

States a specific verb and resource ('find alternatives' for a subscription the user pays for) and pins the scope to a single named product rather than the whole stack, which implicitly separates it from audit_stack/choose_stack. The return shape ('ranked paths re-costed at their price, including a cheaper plan of the same vendor') makes the purpose unambiguous.

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?

Opens with an explicit when-to-use trigger ('the user names one product they pay for and asks for something cheaper, whether it's worth it, or what to switch to') reinforced by three realistic utterances. It stops short of naming sibling alternatives (audit_stack, choose_stack, prepare_negotiation) or stating when not to use this tool, so it is strong context without full routing.

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

get_build_packetGet a build packet (Replace with AI)A

Read-onlyIdempotent

Inspect

Use when the user wants to replace a tool by building their own (Replace with AI): returns SPEC.md, AGENTS.md and the runbook files a coding agent builds from, for a recipe with a build path. A recipe without one returns the assessment files for validating a switch or downgrade instead, never a spec to clone a service. Check packet_kind and next_step before acting. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`recipe_id`	Yes

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavioral value: the conditional return shape for recipes with vs. without a build path, and the directive to inspect packet_kind/next_step. It also discloses data-handling/telemetry scope (what is stored, hashed, or never collected), which is beyond structured fields.

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

Conciseness3/5

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

The trigger condition is usefully front-loaded, but the body is a long run-on clause chain and the trailing privacy/telemetry boilerplate is lengthy relative to selection value. Several sentences do not help an agent choose or invoke the tool.

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 read-only single-parameter tool with no output schema, the description adequately explains what comes back and the two return modes, so an agent knows what to expect. The remaining gap is how to source a valid recipe_id, which is left implicit.

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

Parameters2/5

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

Schema coverage is 0% and there is no description of recipe_id anywhere — no format, no explanation of where to obtain it (e.g., from search_recipes or get_recipe). With one undocumented parameter, the description fails to compensate for the schema gap, so it falls below the 3 baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it returns SPEC.md, AGENTS.md and runbook files for a recipe with a build path, and clarifies the fallback case (assessment files for switch/downgrade validation). The core purpose is clear, though it is wrapped in a dense run-on sentence and the odd 'Replace with AI' phrasing; it also does not name a sibling to contrast against.

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 an explicit trigger condition ('Use when the user wants to replace a tool by building their own') and a handling instruction ('Check packet_kind and next_step before acting'). It does not name alternatives among siblings such as get_recipe or get_exit_plan, so routing is only partially resolved.

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

get_detection_rulesGet code detection rulesA

Read-onlyIdempotent

Inspect

Rules for finding paid services in a codebase on the user's own machine: package names, environment variable name patterns, config files, API hosts and feature patterns for about 100 vendors. Apply them locally and send only the vendor and feature names you found to audit_stack, never code or secret values. Names without rules come back under unknown. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`vendors`	No	Only these vendors, by id or name (default: all)

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so safety is covered; the description adds genuinely new behavior such as the 'unknown' bucket for unmatched names and the local-execution/no-code-egress model. The data-retention details are relevant but partly generic product boilerplate rather than tool-specific behavior.

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

Conciseness3/5

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

The core purpose and the audit_stack routing are correctly front-loaded, but the trailing data-handling sentence runs long with an enumerated list of stored fields that crowds the tool's actual function. It is readable but not tight.

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 zero-required-param, read-only getter with no output schema, the description covers what is returned (rule categories), the fallback behavior, and the privacy boundary, which is enough to call it correctly. It stops short of describing the shape of an individual rule, a minor gap.

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 100% with a single optional 'vendors' parameter, so the schema already carries the semantics (id or name, default all). The description adds only an indirect hint via the 'unknown' fallback and does not explain the id-vs-name distinction. Baseline 3 is appropriate.

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?

States a specific resource and its scope: detection rules for paid services in a codebase, enumerated as package names, env var patterns, config files, API hosts and feature patterns across ~100 vendors. An agent can distinguish this from siblings like get_recipe or search_recipes without opening any schema.

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?

Gives explicit workflow context: apply the rules locally, then send only vendor and feature names to audit_stack, never code or secret values. That routes the agent to the correct sibling and states the constraint, though it does not name a when-not-to-use condition.

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

get_exit_planHow to cancel a subscriptionA

Read-onlyIdempotent

Inspect

Use when the user wants to cancel, unsubscribe from, pause or pay less for something they subscribe to: streaming, music, news, dating, cloud storage, AI tools, apps or business software ('cancel YouTube TV', 'how do I get out of Adobe', 'stop my Audible'). Returns Stackcut's exit plan: every way to cancel by who bills them (the company, Apple, Google Play, a partner or a contract), the steps with the words to expect on screen, when access ends, notice periods, fees and refunds, what to export first, cheaper ways to keep it, and notes for an agent, each fact sourced to the vendor's own page with a check date. Pass billed_by when known (the name on their card statement or receipt) and renewal_date to get the last safe day to cancel. Never cancel for the user without their go-ahead: they sign in, see any offer, and confirm the final step. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`goal`	No
`market`	No	The user's country, e.g. DE: when Stackcut has a guide checked for that market (JP, DE, BR, MX, NL), local_guide points to it
`service`	Yes	The subscription, e.g. 'YouTube TV', 'Adobe Creative Cloud', 'disneyplus.com'
`billed_by`	No	Who charges them (card statement or receipt): the company (direct_web; direct_app in its app), Apple, Google Play, Amazon, Roku, PayPal, a phone or TV provider, a partner or a contract. Omit or 'unknown' for every route and the question to ask. Short words are aliases
`months_left`	No	Monthly payments left (else from renewal_date)
`renewal_date`	No	Next renewal date, YYYY-MM-DD: adds the last safe day to cancel from the documented notice period
`monthly_price`	No	USD a month: with renewal_date or months_left, estimates an early termination fee

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds rich context beyond them: it explains that the tool only returns a plan, that the agent must 'Never cancel for the user without their go-ahead', and details data storage practices (arguments stored, account keys hashed, no IPs). This goes well beyond the safety profile annotations.

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 the primary use case and then systematically covers return format, parameter advice, behavioral caveats, and privacy notes. It is dense but well-structured; however, it is quite long and the privacy section, while useful, could be trimmed without losing essential guidance.

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?

Given 7 parameters, no output schema, and moderate complexity, the description does a thorough job explaining what is returned (every cancellation route, steps, fees, etc.) and key behavioral constraints. It is nearly complete but omits any reference to sibling tools (e.g., search_exits) that an agent might need to choose correctly.

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 86%, so the schema already documents the parameters in detail. The description adds minor usage guidance for billed_by and renewal_date, but does not explain the other five parameters (goal, market, months_left, monthly_price) beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it 'Returns Stackcut's exit plan' with a clear enumeration of contents (cancellation routes by biller, steps, fees, etc.). It does not mention any sibling tool like search_exits, so it lacks explicit sibling differentiation, capping it at 4.

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?

The opening sentence gives a clear when-to-use trigger: 'Use when the user wants to cancel, unsubscribe from, pause or pay less...'. It also advises passing billed_by and renewal_date. However, it never states when *not* to use this tool or names an alternative (e.g., search_exits), so no exclusions are provided.

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

get_my_planGet the user's Stackcut savings planA

Read-onlyIdempotent

Inspect

Use only when the user gives you a Stackcut agent code (it starts with sca_; they copy it from 'Send to my agent' on stackcut.io). Returns their own savings plan: every subscription with its verdict, the proven saving, the proof (receipts, card charges or a sourced price), steps and checks. Walk them through it from the biggest proven saving down and ask before any cancel, purchase or sign-up. The code is read-only and expires. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`code`	Yes	The agent code from stackcut.io, e.g. sca_…

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds material facts beyond them: the code is read-only and expires, results are summarized, and it details what argument data is stored versus hashed or excluded. The tail about exit tools logging counts is tangential to this tool, which slightly dilutes the transparency payoff.

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

Conciseness3/5

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

The precondition and the return summary are front-loaded, which is good. However, a large block of privacy/data-retention text and a sentence about exit tools inflate the description well beyond what an agent needs to select and call this tool.

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

Completeness5/5

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

There is no output schema, so the description carries the burden of describing returns – and it does so thoroughly (verdict, proven saving, proof, steps, checks) while also stating the entry precondition and post-call workflow. Nothing essential for correct invocation is missing.

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

Parameters4/5

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

Schema coverage is 100% and the single 'code' param is already documented with an example, so baseline is 3. The description adds useful provenance the schema lacks: where the code comes from, that it starts with sca_, and that it expires.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Returns their own savings plan') and enumerates exactly what comes back: subscriptions, verdict, proven saving, proof, steps and checks. It distinguishes the tool's scope from query/audit siblings implicitly, but never names an alternative like get_exit_plan or audit_stack, so the differentiation is not explicit.

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?

Gives a clear precondition: use only when the user supplies a Stackcut agent code beginning with sca_, copied from 'Send to my agent'. It also prescribes workflow ('walk them through from the biggest proven saving down and ask before any cancel, purchase or sign-up'). It stops short of naming when-not-to-use or which sibling to pick instead.

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

get_recipeGet a recipeA

Read-onlyIdempotent

Inspect

Full detail for one recipe from search_recipes: every replacement path with modeled first-year savings, monthly cost, setup time and upkeep, what is out of scope, checks to run before switching, how to leave the current vendor (cancel steps, refunds, exports, what you lose), step-by-step playbooks, sources, and Stackcut's own lab results where they exist (not customer results). Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`id`	Yes	Recipe id from search_recipes, e.g. 'crm-pipeline'

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, so the bar is lower, and the description adds what a caller cannot get from annotations: that lab results are Stackcut's own (not customer results), what is explicitly out of scope, and a detailed data-handling disclosure (arguments stored, keys hashed, billing/validation sources excluded, no IPs) plus a 'don't send personal data' warning. It stops short of describing retrieval/pagination behavior, hence 4 rather than 5.

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

Conciseness3/5

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

The opening sentence is dense but well front-loaded, enumerating exactly what the response contains. The trailing privacy/telemetry passage, however, is long boilerplate that is not specific to invoking get_recipe and inflates the definition considerably.

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 no output schema, the description carries the return-value burden and discharges it well, detailing replacement paths, modeled savings, costs, playbooks, sources and lab results. Combined with the fully documented id parameter and the stated privacy constraints, an agent has what it needs to call it correctly; only explicit sibling routing is missing.

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 100% and the single parameter already documents its origin and format ('Recipe id from search_recipes, e.g. crm-pipeline'). The description adds no syntax, constraint, or edge-case meaning beyond that, so the baseline 3 applies.

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?

Opens with a specific verb+resource+scope: 'Full detail for one recipe from search_recipes', and immediately names the sibling that produces the id. An agent can distinguish it from search_recipes and get_workflow_recipe without opening either schema.

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

Usage Guidelines3/5

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

It implies the workflow ('from search_recipes') by tying the id to the search tool, which is genuine routing information. But it never states when to prefer this over get_workflow_recipe, get_exit_plan, or get_my_plan, nor any precondition beyond the id, so usage is only implied.

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

get_usage_questionsUsage questions for vendorsA

Read-onlyIdempotent

Inspect

Before an audit: which usage numbers decide each vendor's answer (emails a month, domains, database size, seats…), where the user finds each one (dashboard page, API, export), and ready-to-ask questions. Units already stated in context are marked as given. Pass the answers to audit_stack or find_alternatives as usage and features_used. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`context`	No	Optional: what is already known, in words (e.g. 'about 40,000 emails/mo, 4 domains'); units it states are marked as given and not asked again
`vendors`	Yes	Vendors they pay for, by name or id, e.g. ['Resend', 'Supabase Pro']

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/no-destruct, so the safety profile is covered. The description adds substantial context beyond that: it explains the "marked as given" behavior for context units, discloses exactly what is stored versus not stored (account keys only as a one-way hash, no IPs, no billing/validation sources), and notes result summarization.

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?

Purpose and workflow routing are front-loaded in the first two sentences, then privacy/logging details follow. The data-handling passage is long, but it is compliance-relevant rather than filler, and every sentence carries content; minor tightening would help.

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 no output schema, the description usefully characterizes returns (the specific question categories and where each answer lives) and the chaining contract. For a two-param, read-only tool this is close to complete, though it doesn't address output size or ordering of the returned questions.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it clarifies that units already stated in context are marked "given" and not asked again, and frames vendors as the paid-for set. That is behavior the schema's field descriptions alone don't convey as clearly.

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 states a specific resource and scope: it returns which usage numbers decide each vendor's answer (emails/month, domains, database size, seats), where the user finds each one, and ready-to-ask questions. It names the sibling tools (audit_stack, find_alternatives) it feeds, so an agent can place it precisely in the workflow.

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 explicit timing ("Before an audit") and an explicit downstream action ("Pass the answers to audit_stack or find_alternatives as usage and features_used"), which is strong routing guidance. It stops short of stating when NOT to use it or naming a competing sibling to avoid.

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

get_workflow_recipeGet an end-to-end workflow recipeA

Read-onlyIdempotent

Inspect

One runbook from search_workflow_recipes in full: the evidence to collect, keep/downsize/consolidate/migrate/build/retire decisions, ordered steps, acceptance tests, rollout, rollback, maintenance, costs still unresolved, and scoped starter templates with their download digest. A reviewed playbook is not a completed customer migration. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`id`	Yes	Workflow id from search_workflow_recipes, e.g. 'portfolio-shared-billing'

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description adds real behavioral context: results are summarized, exit tools log only counts/flags/statuses rather than answer contents, and there is an explicit 'don't send personal data or secrets' guardrail. The caveat 'a reviewed playbook is not a completed customer migration' also usefully frames expectations. The data-storage paragraph reads partly as shared boilerplate rather than tool-specific behavior, which keeps it from a 5.

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

Conciseness3/5

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

The core definition is front-loaded and dense, but the long parenthetical on stored arguments, hashing, and billing sources is verbose boilerplate that does not help select or invoke this specific tool. Roughly half the description is generic service-level privacy prose.

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 no output schema, the description carries the return-content burden and does so well by enumerating the runbook sections. Safety is covered by annotations and data-handling by the privacy paragraph, so an agent has what it needs, though the absence of any error/not-found or size caveat leaves a small gap.

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 100% and the single id parameter is fully documented with format and an example, so parameter_semantics sits at the baseline. The description adds only that the runbook comes from search_workflow_recipes, which the schema already states, and gives no extra guidance on id validity or failure behavior.

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 states exactly what is returned: one runbook from search_workflow_recipes retrieved in full, and enumerates its parts (decisions, ordered steps, acceptance tests, rollout, rollback, maintenance, templates with digest). It clearly distinguishes itself from the search sibling search_workflow_recipes, 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 Guidelines3/5

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

Usage is implied: fetch a full recipe by id after surfacing it via search_workflow_recipes, and the schema reinforces this ('Workflow id from search_workflow_recipes'). However, there is no explicit when-to-use vs. when-not, and no comparison against near siblings like get_recipe, get_exit_plan, or get_build_packet despite the crowded namespace.

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

leaderboardSavings leaderboardB

Read-onlyIdempotent

Inspect

The top replacement paths across the catalog by modeled first-year savings, payback months, or how often people and agents used them. Leaves out partial replacements unless include_partial, and never lists trials, one-time credits, expiring or non-commercial plans. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Default
`limit`	No
`metric`	No	savings
`category`	No
`path_type`	No
`include_partial`	No

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is low, yet the description adds substantial detail: which result classes are never listed, that results are summarized/aggregated, and a detailed data-retention disclosure. It stops short of describing return shape or pagination, keeping it out of the top band.

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?

Purpose and scope are front-loaded in the first sentence, followed by exclusions then privacy. It is longer than typical due to the parenthetical data-handling detail, but every sentence is informative rather than filler.

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

Completeness3/5

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

With no output schema, the description should also characterize the return value; it names the ranking basis and exclusions but not the shape or fields of each returned path. Two enum-ish parameters (category, path_type) also go unexplained, leaving gaps for an agent assembling a call.

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 0% across 5 parameters, so the description carries the burden. It maps the metric enum values to human meanings (savings, payback months, usage frequency) and explains include_partial, but leaves category, path_type (7 enum values) and limit entirely unexplained. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: it returns 'the top replacement paths across the catalog' ranked by one of three metrics, which is a clear, concrete purpose. It does not name or differentiate itself against siblings like find_alternatives or search_exits, but the leaderboard/ranking concept is distinct enough to be inferable.

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

Usage Guidelines2/5

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

The description explains what is included or excluded from results (partial replacements, trials, one-time credits, expiring/non-commercial plans) but never says when to reach for this tool versus find_alternatives, search_exits, or choose_stack. No positive usage triggers or exclusions relative to alternatives are given.

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

list_categoriesList categoriesB

Read-onlyIdempotent

Inspect

The catalog's categories with how many recipes each has and the best modeled first-year saving in each. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare the full safety profile (readOnly, idempotent, closed-world, non-destructive), so the bar is low. The description adds genuine retention context (arguments stored, results summarized, no IPs), but it is a server-wide boilerplate disclaimer rather than tool-specific behavior like ordering or result shape.

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 in sentence one, which is good, but three of four sentences are generic privacy boilerplate that reads as cross-tool filler. For a zero-parameter listing tool this is disproportionately bloated.

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 no output schema, the description usefully spells out what each category row contains (recipe count, best first-year saving), which is the key thing an agent needs. It omits ordering or size constraints, which is a minor gap for a simple catalog listing.

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

Parameters4/5

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

This tool takes zero parameters, so the baseline is 4. There are no arguments whose semantics need explaining, and the description correctly focuses on the result payload instead.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb (list) and resource (categories) plus what each entry contains: recipe counts and best modeled first-year saving. It's clear what the tool returns, but it makes no attempt to distinguish itself from siblings like search_recipes or get_recipe.

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

Usage Guidelines2/5

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

There is no guidance on when to call this versus the many sibling catalog tools (search_recipes, get_recipe, search_workflow_recipes). The remaining sentences are data-handling policy, not usage context, so an agent gets no routing signal.

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

list_stack_jobsList stack jobsA

Read-onlyIdempotent

Inspect

The jobs choose_stack can compare (database, auth, hosting, transactional and inbound email, object storage, LLM APIs, payments, sandboxes, browser automation, queues…) with how many vendors each has, plus the volume units and aliases it accepts. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: exactly which call arguments are stored versus hashed versus never collected, that tool results are summarized, that exit tools log only counts/flags/evidence statuses, and an explicit 'don't send personal data or secrets' warning.

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

Conciseness3/5

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

The purpose is front-loaded, but the opening sentence is a long, nested clause and the remainder is dense privacy/telemetry prose that, while informative, reads as boilerplate appended to the tool description. Every sentence carries content, yet the balance is skewed toward data-handling policy over the tool's own operation.

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 zero-parameter, read-only list tool with no output schema, the description covers what is returned (jobs with vendor counts, units, aliases) and the data-handling expectations, and annotations carry the safety profile. It is largely complete, with the only minor gap being no description of result ordering or size.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline of 4 applies. The description's mention of 'volume units and aliases it accepts' refers to the domain content returned rather than call arguments, so it neither helps nor harms parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource concretely: the jobs choose_stack can compare (database, auth, hosting, email, object storage, LLM APIs, payments, etc.) plus vendor counts, volume units, and aliases. That is a clear verb+resource and it ties the tool to the choose_stack sibling, though it never plainly says 'list' and leans on the reader already knowing what a 'stack job' is.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance, and no mention of how this differs from siblings like list_categories, search_exits, or choose_stack itself. The choose_stack reference implies a workflow context but the agent must infer the ordering on its own.

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

plan_stack_from_specPlan a stack from a product briefA

Read-onlyIdempotent

Inspect

Use when the user shares a product brief or spec and asks what to build it with or what it will cost. Works out the jobs the brief needs (what it rules out, plans for later or already has is never priced), the volumes from its numbers or listed default rates, and its budget; prices the stack at several scales with choose_stack; and returns SPEC.md, AGENTS.md and a manifest for a coding agent. Keyword rules over the brief, no model call: when total.hypothetical is true, confirm the assumed jobs and volumes with the user before quoting the cost. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`spec`	Yes	The product brief (markdown or plain text, up to 20,000 characters): what it does, who uses it, how it makes money, any numbers you know (users, conversion, prices, volumes). Never paste secrets or personal data.
`prefer`	No		cheapest
`scales`	No	MAU targets to price, default [1000, 20000, 200000]
`add_jobs`	No	Jobs to add that the brief doesn't mention
`overrides`	No	Edit the derived assumptions: a volume per MAU per month (per_user) or a fixed monthly total for a job
`exclude_jobs`	No	Derived jobs to drop (job ids)
`limit_per_job`	No
`unit_economics`	No	Revenue model for gross margin per scale: price_usd with conversion_rate, or revenue_per_mau

TDQS

A4/5.0

Behavior4/5

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

Annotations cover safety (readOnly, idempotent, closed-world), and the description adds real behavior beyond them: deterministic keyword rules with no model call, and a mandatory user-confirmation gate when total.hypothetical is true. The data-retention paragraph is substantive but generic boilerplate that even references exit tools unrelated to this one, diluting its value.

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

Conciseness3/5

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

It is front-loaded with the trigger phrase, which is good, but the body is a dense run-on of semicolon-separated clauses and a long storage/privacy block. That privacy text is disproportionately large for a planning tool and mixes in details about exit tools and other result summarization, so not every sentence earns its place.

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 no output schema, the description carries the return-value burden and does name the artifacts produced (SPEC.md, AGENTS.md, manifest). For an 8-parameter tool with nested objects it also explains the derivation pipeline and the revenue/margin angle, leaving only minor gaps around the tuning parameters.

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 75%, so the schema already documents spec, scales, overrides and unit_economics. The description adds meaning for derived-job semantics ('what it rules out, plans for later or already has is never priced') but says nothing about prefer, limit_per_job, add_jobs or exclude_jobs, so it only marginally exceeds the schema.

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?

Specific verb+resource ('Plan a stack from a product brief') plus an actual account of what it does: derives jobs, volumes and budget from a brief, prices at several scales via choose_stack, and returns SPEC.md, AGENTS.md and a manifest. It also discloses the mechanism (keyword rules, no model call), which lets an agent distinguish it from generic stack tools.

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?

'Use when the user shares a product brief or spec and asks what to build it with or what it will cost' is an explicit trigger condition, and the hypothetical-cost confirmation step is spelled out. It names choose_stack as its pricing dependency but does not contrast itself with siblings like audit_stack or choose_stack as entry points.

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

prepare_negotiationPrepare a subscription negotiationA

Read-onlyIdempotent

Inspect

Find documented existing-customer offers, cancellation-flow promotions and renewal negotiation routes for a service. Returns channel- and market-specific paths, vendor sources, freshness, questions and draft request/terms/counteroffer/decline/confirmation scripts. It sends nothing and makes no account changes. Eligibility and offer amounts are unknown until the vendor confirms them. Compare costs only with complete prices, renewal terms, duration, fees and an explicit horizon; amounts must share the current bill's currency and billing cadence. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`fees`	No	All mandatory fees over the comparison period; explicit 0 only if confirmed.
`market`	No	Country code, e.g. US
`service`	Yes
`billed_by`	No
`current_plan`	No
`renewal_date`	No
`monthly_spend`	No	Current bill. Despite the legacy property name, specify whether this amount is monthly or annual.
`offered_price`	No
`renewal_price`	No
`comparison_months`	No
`required_features`	No
`offer_duration_months`	No
`maximum_commitment_months`	No

TDQS

A3.7/5.0

Behavior5/5

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

Goes well beyond the annotations: 'It sends nothing and makes no account changes,' 'Eligibility and offer amounts are unknown until the vendor confirms them,' plus explicit data-handling disclosure about what Stackcut stores (vendor/price/seat/feature/usage data, account keys hashed, billing and validation sources not stored, never IPs) and how results are summarized. This is unusually rich behavioral context for a read-only tool.

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

Conciseness4/5

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

Front-loads purpose and return contents before safety and privacy, so the important material is early. It is dense and the privacy/storage sentence is long, but for a 13-parameter tool with no output schema most of it earns its place.

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 no output schema, the description correctly enumerates what comes back ('channel- and market-specific paths, vendor sources, freshness, questions and draft request/terms/counteroffer/decline/confirmation scripts') and covers safety, data handling and comparison semantics. The main omission is any guidance on picking this tool over overlapping siblings.

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 only 23%, so the description must compensate and it partially does: it maps conceptually to offered/renewal prices, offer duration, fees, comparison horizon, and the currency/billing-cadence constraint tied to monthly_spend. It adds nothing for service, market, billed_by, current_plan, renewal_date, required_features or maximum_commitment_months, leaving a real gap across ~13 params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Find documented existing-customer offers, cancellation-flow promotions and renewal negotiation routes for a service.' This clearly separates it from generic exit/alternatives tools, but it never names a sibling such as search_exits or get_exit_plan, so the agent must infer the boundary itself.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no named alternative. The line 'Compare costs only with complete prices... explicit horizon' is a precondition for good input rather than routing guidance, and nothing tells the agent when NOT to call this versus its many siblings.

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

report_action_outcomeReport an action outcomeA

Idempotent

Inspect

Record a minimal structured report about an attempted cancel, price reduction, negotiation, pause, downgrade, or switch. First call get_exit_plan and send its packet_revision and route_id; stale packet revisions are rejected. Reports are user-reported evidence, never verified execution. The server stores no free text, receipts, messages, or direct identifiers. Reusing client_dedupe_key returns the existing report without inflating counts; blocked or changed-step reports create a review task and never edit a packet automatically. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`action`	Yes
`locale`	Yes	Language tag such as en or en-US
`market`	Yes	Two-letter country code
`blocker`	No	Required for blocked or steps_changed
`channel`	Yes	The selected route's billed_by channel
`outcome`	Yes
`service`	Yes	The service name or id from get_exit_plan
`currency`	No	Required with numeric amounts
`route_id`	Yes	The selected route_id from get_exit_plan
`fees_amount`	No
`effective_on`	No
`offer_amount`	No	Optional reported amount, never treated as verified savings
`renewal_amount`	No
`savings_amount`	No	Optional reported savings amount (negative means costs rose), never treated as verified savings
`packet_revision`	Yes	The current packet_revision from get_exit_plan
`client_dedupe_key`	Yes	A fresh opaque idempotency key; never use an email, account id, or other personal value
`commitment_months`	No
`offer_billing_period`	No
`offer_duration_months`	No

TDQS

A4.2/5.0

Behavior5/5

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

Goes well past the annotations: reports are unverified user-reported evidence, blocked/steps_changed outcomes spawn a review task, packets are never auto-edited, and it discloses exactly what argument data is retained, hashed, or excluded. The dedupe-reuse behavior is consistent with idempotentHint=true and the write semantics match readOnlyHint=false, so there is no contradiction.

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?

Purpose, prerequisite, behavior, and data policy are delivered in a front-loaded sequence with no filler sentences. It is long and the telemetry paragraph partly overlaps the earlier 'stores no free text, receipts, messages, or direct identifiers' claim, but the density of information justifies most of the length.

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 19-parameter, no-output-schema mutation tool this covers a lot: inputs provenance, rejection behavior, downstream effects, and data handling. The notable gap is disambiguation from report_outcome and report_exit_outcome, which an agent needs in order to pick this tool at all.

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

Parameters4/5

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

With 19 parameters at 58% schema coverage, the description meaningfully supplements the schema: packet_revision freshness rules, route_id provenance from get_exit_plan, and client_dedupe_key reuse semantics that map to a report-returning idempotent call. It doesn't cover the remaining undocumented amount/commitment fields, but the highest-risk parameters are addressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (record) and resource (a structured report) and enumerates the six action types it covers (cancel, pay_less, renegotiate, pause, downgrade, switch), so the domain is unambiguous. It does not, however, differentiate itself from close siblings like report_outcome or report_exit_outcome, leaving the agent to guess which report tool applies.

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?

Gives an explicit ordering prerequisite: call get_exit_plan first and pass its packet_revision and route_id, with stale revisions rejected. It describes the triggering context (after an attempted action) but offers no when-not guidance or alternative-tool routing against the three sibling report tools.

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

report_exit_outcomeReport how a cancellation wentAInspect

After the user reports what happened, count a cancellation, keeping the service for less, getting blocked, or changed steps. This updates only an anonymous usage counter and does not verify an action. Use report_action_outcome for a durable report tied to the current packet revision and route. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`step`	No	For blocked or steps_changed: include the step number where it stopped matching, when known
`outcome`	Yes
`service`	Yes	The service, as passed to get_exit_plan
`billed_by`	Yes	The route they used: its billed_by from get_exit_plan (get_exit_plan's aliases are read as their channel here too)

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses what the write actually does ('updates only an anonymous usage counter and does not verify an action') and gives a detailed data-handling profile: what arguments are stored, that account keys are one-way hashed, that billing/validation sources are not stored, and that no IP addresses are collected. This is substantive behavior the annotations do not convey.

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?

Front-loads the core action and the routing to the sibling before the privacy block. The data-handling sentences are dense and multi-clause but each carries relevant information, so only mild trimming is warranted.

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 no output schema and a mutation tool (readOnlyHint=false), the description supplies the necessary behavioral and data-retention context and defers parameter details to a mostly-covered schema. It is nearly complete; only finer details of the return/response side are unstated, which is acceptable given no output schema.

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%: service, billed_by, and step carry descriptions, and the outcome enum is mostly self-explanatory. The description restates the outcome categories but adds no syntax, format, or edge-case meaning beyond the schema, so a baseline 3 is appropriate.

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 states a specific action and scope: counting a cancellation outcome (cancelled, kept_for_less, blocked, steps_changed) after the user reports it. It explicitly names the sibling report_action_outcome and the distinguishing condition, so an agent can separate it from that tool without reading 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?

Gives an explicit timing cue ('After the user reports what happened') and an explicit alternative with its selection condition ('Use report_action_outcome for a durable report tied to the current packet revision and route'). It also draws the boundary that this does not verify an action, which further disambiguates usage.

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

report_guide_feedbackReport guide feedbackA

Idempotent

Inspect

After using guidance, report a missing vendor or billing route, a mismatching step, unavailable source, incomplete instructions, unexpected fee, observed retention offer, required human handoff, or that the guide matched. Send only the structured fields, never account information, URLs, screenshots or text. Current packet routes and step numbers are validated; stale revision reports are kept as unverified provenance. An acknowledgement records feedback for review, never completion or a published fix. Retry with the same opaque key when delivery is uncertain. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`kind`	Yes
`locale`	No
`market`	No
`channel`	No
`service`	No
`route_id`	No
`step_index`	No
`vendor_domain`	No	For vendor_missing only: public registrable vendor domain such as example.com, without URL, path, query or account subdomain
`handoff_reason`	No
`packet_revision`	No
`client_dedupe_key`	Yes	Opaque retry key, never a personal value
`handoff_expectation`	No

TDQS

A4.1/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, idempotentHint=true) by explaining that an acknowledgement 'records feedback for review, never completion or a published fix', that stale revision reports are retained as unverified provenance, and by disclosing exactly what Stackcut persists and what it never stores. Retry semantics reinforce the idempotency hint with actionable detail.

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?

Front-loaded with the reportable conditions before constraints, retry rules and privacy disclosure. The data-retention sentence is long and parenthetical-heavy, but each sentence carries distinct information rather than repeating the schema.

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 write-report tool with no output schema and a low-coverage input schema, the description covers outcome semantics (acknowledgement ≠ fix), retry behavior, and privacy boundaries. It omits any auth/permission requirements and does not clarify whether fields are conditionally required per kind.

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 only 17% for 12 parameters, so the description must carry more weight. It does add meaning for a few fields (opaque retry key, current packet routes/step numbers validated, stale packet_revision handling) and restricts free-form input, but it leaves locale, market, channel, service and handoff fields undocumented by either source.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource and enumerates the nine reportable conditions, which aligns cleanly with the `kind` enum. The phrase 'After using guidance' implicitly separates this from report_action_outcome and report_exit_outcome, but no sibling is named explicitly, so it stops short of a 5.

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 states the triggering context ('After using guidance') and gives concrete usage constraints: send only structured fields, never URLs/screenshots/text, and retry with the same opaque key when delivery is uncertain. It does not, however, tell the agent when to prefer a different reporting tool.

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

report_outcomeReport what the user didBInspect

Only after the user confirms what they did: record that they picked, switched to or reverted from a replacement path. Adds one to anonymous public counters and stores no personal data. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`outcome`	Yes
`path_id`	Yes
`recipe_id`	Yes

TDQS

B3.3/5.0

Behavior4/5

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

Annotations only tell us it is a non-idempotent, non-destructive write. The description adds substantive behavior: it increments anonymous public counters, stores no personal data, and details what Stackcut retains versus discards. This is real disclosure beyond structured fields, though the long privacy paragraph is partly general policy rather than tool-specific behavior.

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

Conciseness3/5

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

The precondition and core action are front-loaded well. However, the middle block is a dense data-retention policy paragraph whose sentences (tool result summarization, exit-tool logging details) drift away from what this specific tool does.

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

Completeness3/5

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

With no output schema and 0% parameter coverage, the description should cover inputs and return effects more fully. It handles when-to-call and privacy well, but never clarifies what recipe_id/path_id refer to or what a successful report yields, leaving gaps for a 3-required-parameter write tool.

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

Parameters2/5

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

Schema description coverage is 0% for three required parameters, so the description must carry the load. It does map the outcome enum values ('picked, switched to or reverted from'), but recipe_id and path_id are never explained, leaving two of three required arguments semantically opaque.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (record) plus the exact outcomes recorded ('picked, switched to or reverted from a replacement path'), so the agent knows this reports a user's path decision. It does not, however, distinguish itself from the sibling report_action_outcome and report_exit_outcome tools, leaving the boundary to inference.

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

Usage Guidelines3/5

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

'Only after the user confirms what they did' gives a clear precondition, and the later mention of 'exit tools' implies a scope boundary. But it never names the alternatives (report_action_outcome, report_exit_outcome) or states when this one is preferred over them, so the routing decision is only partly supported.

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

search_discoveriesSearch reviewed software discoveriesB

Read-onlyIdempotent

Inspect

Find human-reviewed research notes about new products, replacement workflows, changed flows and build-versus-buy lessons. Returns original posts and primary sources with explicit author-reported versus documented claims and unknown costs. These are research notes, not tested recipes or verified savings. Private queue drafts are never returned. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`kind`	No
`limit`	No
`query`	No
`vendor`	No

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed world), so the bar is lower. The description still adds real substance: it discloses that results carry author-reported vs documented claims and unknown costs, that private queue drafts are never returned, and details what call arguments are stored. It leans heavily on privacy boilerplate that partly concerns other tools, keeping it from a 5.

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

Conciseness3/5

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

The core purpose is front-loaded in the first sentence, which is good. But the back half is a long, parenthesis-heavy data-retention notice that reads as boilerplate and buries useful return-value detail in run-on phrasing.

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

Completeness3/5

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

There is no output schema, and the description partially compensates by describing what is returned (original posts, primary sources, claim provenance). But with zero parameter coverage and no explicit disambiguation from sibling search tools, the definition is only adequate for an agent deciding how to invoke it.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry the burden for all four parameters. The enumerated subjects loosely hint at the 'kind' enum values, but query, vendor, and limit (with its 1-30 cap) are never explained, leaving the filtering semantics largely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Find') and resource ('human-reviewed research notes'), and enumerates the concrete subjects covered (new products, replacement workflows, changed flows, build-versus-buy lessons) which maps onto the kind enum. It also distinguishes itself from recipe/exercise siblings by warning these are 'not tested recipes or verified savings.' It does not name a sibling tool directly, so it falls just short of 5.

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

Usage Guidelines3/5

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

The framing ('research notes, not tested recipes or verified savings') gives implicit guidance that this is for exploratory sourcing rather than vetted implementation, which helps route away from search_recipes/get_recipe. However, no explicit when-to-use condition or named alternative is given, and there is no statement of prerequisites.

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

search_exitsBrowse the cancel libraryA

Read-onlyIdempotent

Inspect

Lists services in Stackcut's cancel library (streaming, music, news, dating, cloud storage, AI tools, apps and software), by name, domain or category, with the page and JSON for each. Use get_exit_plan for one service's steps. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`limit`	No	At most 100 are returned
`query`	No	A name or domain, e.g. 'peacock', 'vpn'
`action`	No	Filter for a documented action pathway
`category`	No

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower; the description still adds what the response contains ('the page and JSON for each') and a detailed data-handling disclosure (arguments logged, results summarized, account keys hashed, no IPs). The logging/compliance detail is genuinely beyond the annotations, though it is more a data policy than operational behavior like rate limits or pagination.

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

Conciseness3/5

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

The purpose sentence is front-loaded and efficient, but more than half the text is a long parenthetical privacy/telemetry block that is boilerplate-heavy for a read-only browse call. The closing 'Don't send personal data or secrets' is useful, yet the nesting makes the tail hard to scan.

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 no output schema, the description usefully states that each result includes a page and JSON, which is exactly the return-value gap it needs to fill. It still leaves the action filter and result-count behavior undescribed, but for a 4-parameter, all-optional browse tool the coverage 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%, so the schema already documents limit, query, and category with enum values; the description's 'by name, domain or category' largely restates those. It never mentions the 'action' parameter (cancel/pay_less/renegotiate) or the 100-result cap, so it does not compensate for the coverage gap.

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?

Specific verb ('Lists') plus resource ('services in Stackcut's cancel library'), with the domain examples (streaming, music, news...) and the return shape ('the page and JSON for each') spelled out. It explicitly contrasts itself with get_exit_plan, so an agent can separate this browse tool from the single-service sibling without reading either schema.

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 one explicit routing rule — use get_exit_plan for a single service's steps — which is the closest alternative. However it does not distinguish search_exits from other plausible siblings such as find_alternatives, choose_stack, or audit_stack, and it never states when a query/category filter is warranted versus browsing unfiltered.

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

search_recipesSearch replacement recipesA

Read-onlyIdempotent

Inspect

Use when the user wants a cheaper way to do a job and names a feature or kind of tool rather than one product: 'cheaper keyword research', 'forms without Typeform', 'what can replace our CRM'. Filter by the vendor they pay for, a feature, a category or a path type (switch, cheaper plan, open source, pay per use, agent skill, build it). Returns compact recipe cards, each with its best priced path that saves money; get_recipe has every path, cost and source. intent 'new' prices options for a job they don't pay for yet; requirements labels must-haves. For one product they pay for, find_alternatives re-costs it at their own price and usage. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description	Default
`sort`	No		relevance
`limit`	No
`query`	No	Free text, e.g. 'client approval portal' or 'semrush backlinks'
`intent`	No	new: they pay for no tool yet: costs, never savings (default replace)
`vendor`	No	Product currently paid for, e.g. 'Airtable', 'Salesforce', 'Semrush Pro'
`feature`	No	A feature they rely on, e.g. 'rank tracking', 'e-signatures'
`category`	No	Category name from list_categories, e.g. 'CRM', 'SEO data'
`path_type`	No	Only recipes offering this kind of replacement
`requirements`	No	Options per recipe: excluded kinds dropped, must-haves labeled

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (readOnly/idempotent/non-destructive/non-openWorld), the description discloses data-handling behavior: Stackcut stores call arguments, account keys only as a one-way hash, never billing/validation sources or IP addresses; results are summarized and exit tools log only counts/flags. It also warns 'Don't send personal data or secrets.' This is rich behavioral context not present in structured fields.

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?

Usage/scoping is front-loaded and each section (filters, returns, alternatives, privacy) is information-dense rather than filler. It is nonetheless long and the privacy/tool-call-storage passage is verbose, slightly diluting focus for an agent scanning for the call parameters.

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 9 params, nested requirements, and no output schema, the description adequately covers return shape ('compact recipe cards', path with savings) and points to get_recipe for full detail. It covers query shapes well, though it does not explain sort/limit behavior, leaving a small gap.

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 78%, so the schema already documents most params including intent, vendor, feature, category, path_type and requirements sub-fields. The description summarizes how filters combine and clarifies intent/requirements semantics, but largely reinforces rather than adds syntax beyond the schema, so the baseline 3 is appropriate.

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 states a specific verb+resource ('search replacement recipes', 'returns compact recipe cards, each with its best priced path that saves money') and clearly distinguishes itself from siblings by naming get_recipe (full paths/cost/source) and find_alternatives (re-cost one product you pay for). An agent can tell it apart from these without opening any schema.

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

Usage Guidelines5/5

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

It opens with an explicit 'Use when...' condition and concrete query examples ('cheaper keyword research', 'forms without Typeform'), then routes to alternatives: get_recipe for every path and find_alternatives for a single paid product. Intent 'new' vs 'replace' and requirements are explained, so the when-to-use and when-not-to-use rules are fully spelled out.

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

search_workflow_recipesFind end-to-end workflow recipesA

Read-onlyIdempotent

Inspect

Use for a whole operational change rather than one subscription: billing shared across projects, moving hosting or email, retiring a dormant project, cheaper AI model routing, queues, auth or storage. Returns reviewed runbooks with the query words they matched; get_workflow_recipe returns one in full. Runbooks are guidance, not proof that a migration ran. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`limit`	No
`query`	No	The job in words, e.g. 'shared billing across projects' or 'queue retries worker'
`vendor`	No	Only runbooks tagged for this vendor id, e.g. 'stripe', 'supabase'

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description goes well beyond them: it discloses the return shape (reviewed runbooks plus matched query words), the epistemic caveat that runbooks are guidance not proof, and a detailed data-handling disclosure covering exactly which call arguments are stored, that account keys are one-way hashed, that billing and validation sources are excluded, that IPs are never stored, and what exit tools log. This is unusually rich behavioral context for a search tool.

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

Conciseness4/5

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

Purpose and routing are front-loaded in the first two sentences, and the privacy disclosure is dense but relevant to a tool that stores arguments. The clause about exit tools logging result counts is somewhat tangential to this search tool and adds length without helping an agent invoke it, keeping it short of a 5.

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

Completeness5/5

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

With no output schema, the description must describe returns, and it does: reviewed runbooks with the query words they matched, plus the pointer to get_workflow_recipe for full content. It also covers the data-governance obligations an agent needs to know before sending arguments (no personal data or secrets). Nothing material is left for the agent to infer.

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 67%: 'query' and 'vendor' are documented in the schema, while 'limit' is not. The description adds only that results come 'with the query words they matched', which hints at matching behavior but gives no extra syntax, format or constraint detail beyond the schema. Baseline 3 is appropriate.

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?

Opens with an explicit use scope ('a whole operational change rather than one subscription') and backs it with concrete examples (shared billing, moving hosting or email, retiring a dormant project, model routing, queues, auth, storage). It also explicitly distinguishes itself from the sibling get_workflow_recipe, which returns one recipe in full, so an agent can route correctly without reading the schema.

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?

States when to reach for this tool (whole operational change, not a single subscription), names the alternative tool for the follow-up step (get_workflow_recipe returns one in full), and warns that runbooks are guidance rather than proof a migration ran. When-to-use, when-to-escalate and the caveat are all present.

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

start_auditStart a stack audit (baseline)A

Read-onlyIdempotent

Inspect

Start here when the user wants to cut spend across several tools, consolidate apps, or replace one tool safely, and the bills alone won't decide it. Send vendors and team_size (or a stack manifest) and get the few missing facts that would change the answer, ranked by what's at stake, each with where to find it. Fetch those, add them, and call again until status is 'enough', then call next.tool with next.arguments. Send counts, prices, feature and job names only, never raw exports, customer data, secrets or people's names. Stackcut stores the arguments of tool calls to improve its recommendations (vendor names, prices, seats, features, usage numbers, billing amounts and project descriptions; account keys only as a one-way hash, billing and validation sources not at all; never IP addresses). Tool results are summarized; exit tools log only result counts, qualification flags and public evidence statuses, not answer contents. Don't send personal data or secrets.

Name	Required	Description
`vendors`	No	A first pass without a manifest: the tools the team pays for, e.g. ['Notion', 'Asana', 'Loom'].
`decision`	No	With vendors: what the audit is for (default cut_spend).
`manifest`	No	A stack manifest (JSON Schema at https://stackcut.io/schemas/stack-manifest-1.json; manifest_version '1'): goal, org, builder, services (vendor, plan, monthly_spend_usd, seats, active_users, features_used, usage, renewal_date, …), workflows, unknowns.
`team_size`	No	With vendors: people on the team.
`max_questions`	No	Most questions to return (default 8).

TDQS

A4.2/5.0

Behavior5/5

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

Annotations establish read-only/idempotent/non-destructive, and the description goes well beyond them: it discloses that call arguments are stored to improve recommendations, enumerates what is persisted (vendors, prices, seats, features, usage, billing) versus excluded (account keys hashed, billing/validation sources, IPs), notes results are summarized, and states exit tools log only counts/flags. This is unusually rich behavioral and data-handling disclosure.

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

Conciseness3/5

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

The purpose is front-loaded and the loop instructions are useful, but the description is a single dense block that mixes when-to-use, iteration mechanics, and a long retention/privacy disclosure. It also repeats the data-safety rule twice ('never raw exports, customer data, secrets or people's names' and again 'Don't send personal data or secrets'), which is redundant.

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

Completeness5/5

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

With no output schema, the description compensates by describing the return shape (missing facts ranked by stakes, each with where to find it, a status field, and next.tool/next.arguments) and the terminal condition ('enough'). For a multi-step tool with a nested manifest object, this is complete enough for an agent to drive the flow correctly.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3. The description adds real semantic value by explaining the relationship between parameters ('Send vendors and team_size (or a stack manifest)') and constraining values ('counts, prices, feature and job names only'), but it says nothing about decision or max_questions, so it does not fully rise to a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource (start a stack audit) and frames itself as the entry point: 'Start here when the user wants to cut spend across several tools, consolidate apps, or replace one tool safely.' An agent can tell it's the beginning of an iterative audit flow. It does not explicitly distinguish itself from the similarly named sibling audit_stack, so it falls short of a 5.

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 triggering conditions ('when the user wants to cut spend... and the bills alone won't decide it') and prescribes the full loop: send vendors/team_size, answer the returned questions, re-call until status is 'enough', then invoke next.tool with next.arguments. It stops short of naming when NOT to use it or pointing to audit_stack as the alternative, so it is not fully explicit about alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 15, 2026
- Addedsearch_discoveries

4 tool updatesOct 8, 2026

Changedaudit_stack3 fields changed

changedInput schema / properties / services / items / properties / usage / description

Previous value: -"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, identified_events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, boards, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."New value: +"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, identified_events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, boards, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month, hosts, tickets_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."

addedInput schema / properties / services / items / properties / usage / properties / hosts
```
Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / tickets_per_month
```
Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}
```

Changedchoose_stack3 fields changed

changedInput schema / properties / needs / items / properties / per_user / items / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "searches_per_hour",
-  "sms_per_month",
-  "vectors_stored",
-  "vector_queries_per_month",
-  "cache_commands_per_month",
-  "mtu",
-  "gpu_seconds_per_month",
-  "revenue_usd_per_month",
-  "phone_minutes_per_month",
-  "vector_read_units_per_month",
-  "vector_write_units_per_month",
-  "identified_events_per_month",
-  "boards",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads",
-  "sms",
-  "vectors",
-  "vector_queries",
-  "cache_commands",
-  "gpu_seconds",
-  "gpu_hours",
-  "revenue_usd",
-  "phone_minutes"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "identified_events_per_month",
+  "boards",
+  "hosts",
+  "tickets_per_month",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

changedInput schema / properties / needs / items / properties / volume / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "searches_per_hour",
-  "sms_per_month",
-  "vectors_stored",
-  "vector_queries_per_month",
-  "cache_commands_per_month",
-  "mtu",
-  "gpu_seconds_per_month",
-  "revenue_usd_per_month",
-  "phone_minutes_per_month",
-  "vector_read_units_per_month",
-  "vector_write_units_per_month",
-  "identified_events_per_month",
-  "boards",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads",
-  "sms",
-  "vectors",
-  "vector_queries",
-  "cache_commands",
-  "gpu_seconds",
-  "gpu_hours",
-  "revenue_usd",
-  "phone_minutes"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "identified_events_per_month",
+  "boards",
+  "hosts",
+  "tickets_per_month",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

changedInput schema / properties / needs / items / properties / volumes / items / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "searches_per_hour",
-  "sms_per_month",
-  "vectors_stored",
-  "vector_queries_per_month",
-  "cache_commands_per_month",
-  "mtu",
-  "gpu_seconds_per_month",
-  "revenue_usd_per_month",
-  "phone_minutes_per_month",
-  "vector_read_units_per_month",
-  "vector_write_units_per_month",
-  "identified_events_per_month",
-  "boards",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads",
-  "sms",
-  "vectors",
-  "vector_queries",
-  "cache_commands",
-  "gpu_seconds",
-  "gpu_hours",
-  "revenue_usd",
-  "phone_minutes"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "identified_events_per_month",
+  "boards",
+  "hosts",
+  "tickets_per_month",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

Changedfind_alternatives3 fields changed

changedInput schema / properties / usage / description

Previous value: -"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, identified_events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, boards, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."New value: +"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, identified_events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, boards, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month, hosts, tickets_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."

addedInput schema / properties / usage / properties / hosts

Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / usage / properties / tickets_per_month

Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}

Changedplan_stack_from_spec1 field changed

changedInput schema / properties / overrides / items / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "searches_per_hour",
-  "sms_per_month",
-  "vectors_stored",
-  "vector_queries_per_month",
-  "cache_commands_per_month",
-  "mtu",
-  "gpu_seconds_per_month",
-  "revenue_usd_per_month",
-  "phone_minutes_per_month",
-  "vector_read_units_per_month",
-  "vector_write_units_per_month",
-  "identified_events_per_month",
-  "boards",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads",
-  "sms",
-  "vectors",
-  "vector_queries",
-  "cache_commands",
-  "gpu_seconds",
-  "gpu_hours",
-  "revenue_usd",
-  "phone_minutes"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "identified_events_per_month",
+  "boards",
+  "hosts",
+  "tickets_per_month",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

1 tool updateOct 8, 2026

Changedget_exit_plan1 field changed

addedInput schema / properties / market / description

Added value: +"The user's country, e.g. DE: when Stackcut has a guide checked for that market (JP, DE, BR, MX, NL), local_guide points to it"

2 tool updatesOct 7, 2026

Changedreport_action_outcome7 fields changed

addedInput schema / properties / commitment_months

Added value: +{
+  "maximum": 1200,
+  "minimum": 0,
+  "type": "integer"
+}

changedInput schema / properties / currency / description

Previous value: -"Required with either numeric amount"New value: +"Required with numeric amounts"

addedInput schema / properties / effective_on

Added value: +{
+  "maxLength": 2000,
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

addedInput schema / properties / fees_amount

Added value: +{
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / offer_billing_period

Added value: +{
+  "enum": [
+    "month",
+    "year",
+    "week",
+    "one_time"
+  ],
+  "maxLength": 2000,
+  "type": "string"
+}

addedInput schema / properties / offer_duration_months

Added value: +{
+  "maximum": 1200,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / renewal_amount

Added value: +{
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "number"
+}

Addedreport_guide_feedback

5 tool updatesOct 6, 2026

Changedget_exit_plan2 fields changed

addedInput schema / properties / goal

Added value: +{
+  "enum": [
+    "cancel",
+    "pay_less",
+    "renegotiate"
+  ],
+  "maxLength": 2000,
+  "type": "string"
+}

addedInput schema / properties / market

Added value: +{
+  "maxLength": 2000,
+  "pattern": "^[A-Z]{2}$",
+  "type": "string"
+}

Addedprepare_negotiation
Addedreport_action_outcome

Changedreport_exit_outcome1 field changed

changedInput schema / properties / step / description

Previous value: -"For blocked or steps_changed: the step number where it stopped matching"New value: +"For blocked or steps_changed: include the step number where it stopped matching, when known"

Changedsearch_exits1 field changed

addedInput schema / properties / action

Added value: +{
+  "description": "Filter for a documented action pathway",
+  "enum": [
+    "cancel",
+    "pay_less",
+    "renegotiate"
+  ],
+  "maxLength": 2000,
+  "type": "string"
+}

8 tool updatesOct 5, 2026

Changedaudit_stack4 fields changed

addedInput schema / properties / decision

Added value: +{
+  "description": "consolidate: overlaps on every job each tool does",
+  "enum": [
+    "cut_spend",
+    "consolidate",
+    "replace_one",
+    "choose_stack",
+    "check_in"
+  ],
+  "maxLength": 2000,
+  "type": "string"
+}

changedInput schema / properties / services / items / properties / usage / description

Previous value: -"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."New value: +"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, identified_events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, boards, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."

addedInput schema / properties / services / items / properties / usage / properties / boards
```
Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / identified_events_per_month
```
Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}
```

Changedchoose_stack3 fields changed

changedInput schema / properties / needs / items / properties / per_user / items / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "searches_per_hour",
-  "sms_per_month",
-  "vectors_stored",
-  "vector_queries_per_month",
-  "cache_commands_per_month",
-  "mtu",
-  "gpu_seconds_per_month",
-  "revenue_usd_per_month",
-  "phone_minutes_per_month",
-  "vector_read_units_per_month",
-  "vector_write_units_per_month",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads",
-  "sms",
-  "vectors",
-  "vector_queries",
-  "cache_commands",
-  "gpu_seconds",
-  "gpu_hours",
-  "revenue_usd",
-  "phone_minutes"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "identified_events_per_month",
+  "boards",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

changedInput schema / properties / needs / items / properties / volume / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "searches_per_hour",
-  "sms_per_month",
-  "vectors_stored",
-  "vector_queries_per_month",
-  "cache_commands_per_month",
-  "mtu",
-  "gpu_seconds_per_month",
-  "revenue_usd_per_month",
-  "phone_minutes_per_month",
-  "vector_read_units_per_month",
-  "vector_write_units_per_month",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads",
-  "sms",
-  "vectors",
-  "vector_queries",
-  "cache_commands",
-  "gpu_seconds",
-  "gpu_hours",
-  "revenue_usd",
-  "phone_minutes"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "identified_events_per_month",
+  "boards",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

changedInput schema / properties / needs / items / properties / volumes / items / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "searches_per_hour",
-  "sms_per_month",
-  "vectors_stored",
-  "vector_queries_per_month",
-  "cache_commands_per_month",
-  "mtu",
-  "gpu_seconds_per_month",
-  "revenue_usd_per_month",
-  "phone_minutes_per_month",
-  "vector_read_units_per_month",
-  "vector_write_units_per_month",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads",
-  "sms",
-  "vectors",
-  "vector_queries",
-  "cache_commands",
-  "gpu_seconds",
-  "gpu_hours",
-  "revenue_usd",
-  "phone_minutes"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "identified_events_per_month",
+  "boards",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

Changedfind_alternatives3 fields changed

changedInput schema / properties / usage / description

Previous value: -"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."New value: +"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, identified_events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, boards, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."

addedInput schema / properties / usage / properties / boards

Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / usage / properties / identified_events_per_month

Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}

Changedget_exit_plan4 fields changed

changedInput schema / properties / billed_by / description

Previous value: -"Who charges them (their card statement or receipt says): the company itself (direct_web), Apple, Google Play, Amazon, a phone/TV provider, a partner, or a business contract. Leave out or 'unknown' to get every route and the question to ask"New value: +"Who charges them (card statement or receipt): the company (direct_web; direct_app in its app), Apple, Google Play, Amazon, Roku, PayPal, a phone or TV provider, a partner or a contract. Omit or 'unknown' for every route and the question to ask. Short words are aliases"

changedInput schema / properties / billed_by / enum

Previous value: -[
-  "direct_web",
-  "direct_app",
-  "apple_app_store",
-  "google_play",
-  "amazon",
-  "roku",
-  "paypal",
-  "carrier_or_isp",
-  "reseller_or_partner",
-  "sales_contract",
-  "unknown"
-]New value: +[
+  "direct_web",
+  "direct_app",
+  "apple_app_store",
+  "google_play",
+  "amazon",
+  "roku",
+  "paypal",
+  "carrier_or_isp",
+  "reseller_or_partner",
+  "sales_contract",
+  "unknown",
+  "apple",
+  "app_store",
+  "ios",
+  "itunes",
+  "google",
+  "android",
+  "play",
+  "carrier",
+  "isp",
+  "phone",
+  "cable",
+  "tv_provider",
+  "partner",
+  "bundle",
+  "reseller",
+  "marketplace",
+  "web",
+  "website",
+  "direct",
+  "online",
+  "company",
+  "app",
+  "in_app",
+  "contract",
+  "sales",
+  "enterprise",
+  "invoice"
+]

addedInput schema / properties / monthly_price

Added value: +{
+  "description": "USD a month: with renewal_date or months_left, estimates an early termination fee",
+  "maximum": 100000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / months_left

Added value: +{
+  "description": "Monthly payments left (else from renewal_date)",
+  "maximum": 120,
+  "minimum": 0,
+  "type": "integer"
+}

Changedplan_stack_from_spec1 field changed

changedInput schema / properties / overrides / items / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "searches_per_hour",
-  "sms_per_month",
-  "vectors_stored",
-  "vector_queries_per_month",
-  "cache_commands_per_month",
-  "mtu",
-  "gpu_seconds_per_month",
-  "revenue_usd_per_month",
-  "phone_minutes_per_month",
-  "vector_read_units_per_month",
-  "vector_write_units_per_month",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads",
-  "sms",
-  "vectors",
-  "vector_queries",
-  "cache_commands",
-  "gpu_seconds",
-  "gpu_hours",
-  "revenue_usd",
-  "phone_minutes"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "identified_events_per_month",
+  "boards",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

Changedreport_exit_outcome1 field changed

addedInput schema / properties / billed_by / description

Added value: +"The route they used: its billed_by from get_exit_plan (get_exit_plan's aliases are read as their channel here too)"

Changedsearch_exits3 fields changed

changedInput schema / properties / category / enum

Previous value: -[
-  "streaming_video",
-  "music_audio",
-  "news_magazines",
-  "dating",
-  "cloud_storage",
-  "productivity",
-  "ai_tools",
-  "design_creative",
-  "developer_tools",
-  "marketing_sales",
-  "communication",
-  "security_privacy",
-  "education_learning",
-  "health_fitness",
-  "gaming",
-  "shopping_memberships",
-  "finance_apps",
-  "other_digital"
-]New value: +[
+  "streaming_video",
+  "music_audio",
+  "news_magazines",
+  "dating",
+  "cloud_storage",
+  "productivity",
+  "ai_tools",
+  "design_creative",
+  "developer_tools",
+  "marketing_sales",
+  "communication",
+  "security_privacy",
+  "education_learning",
+  "health_fitness",
+  "gaming",
+  "shopping_memberships",
+  "finance_apps",
+  "other_digital",
+  "customer_support",
+  "business_finance"
+]

addedInput schema / properties / limit / description
```
Added value: +"At most 100 are returned"
```
changedInput schema / properties / limit / maximum
```
Previous value: -100New value: +1000000000000
```

Changedsearch_recipes2 fields changed

addedInput schema / properties / intent

Added value: +{
+  "description": "new: they pay for no tool yet: costs, never savings (default replace)",
+  "enum": [
+    "new",
+    "replace"
+  ],
+  "maxLength": 2000,
+  "type": "string"
+}

addedInput schema / properties / requirements

Added value: +{
+  "additionalProperties": false,
+  "description": "Options per recipe: excluded kinds dropped, must-haves labeled",
+  "properties": {
+    "budget_monthly_usd": {
+      "maximum": 1000000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "exclude": {
+      "description": "self_hosted: on your own server; bundled: needs a suite they'd pay for",
+      "items": {
+        "enum": [
+          "self_hosted",
+          "open_source",
+          "build",
+          "agent_skill",
+          "bundled",
+          "per_use",
+          "free_tier",
+          "trial",
+          "per_seat",
+          "non_commercial"
+        ],
+        "maxLength": 2000,
+        "type": "string"
+      },
+      "maxItems": 10,
+      "type": "array",
+      "uniqueItems": true
+    },
+    "must_have": {
+      "description": "e.g. ['file uploads', 'SSO']",
+      "items": {
+        "maxLength": 200,
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 20,
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

3 tool updatesSep 30, 2026
- Addedget_exit_plan
- Addedreport_exit_outcome
- Addedsearch_exits
10 tool updatesSep 26, 2026
- Changedaudit_stack82 fields changed
  - addedInput schema / properties / services / items / properties / billing
```
Added value: +{
+  "additionalProperties": false,
+  "description": "Billing evidence: scope (dedicated, shared or unknown), account_id (a non-secret alias; the account key), allocated_monthly_usd (attribution only, never a saving), avoidable_monthly_usd with avoidability_confirmed (what leaving actually removes from the bill; 0 is valid), commitment_months_remaining (non-refundable months left; 0 only when cancellable now) and source (a reference, no private contents). With billing, a path is eligible only once the avoidable amount, scope, commitment and source are all given",
+  "properties": {
+    "account_id": {
+      "maxLength": 200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "allocated_monthly_usd": {
+      "maximum": 1000000000000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "avoidability_confirmed": {
+      "type": "boolean"
+    },
+    "avoidable_monthly_usd": {
+      "maximum": 1000000000000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "commitment_months_remaining": {
+      "maximum": 120,
+      "minimum": 0,
+      "type": "number"
+    },
+    "scope": {
+      "enum": [
+        "dedicated",
+        "shared",
+        "unknown"
+      ],
+      "maxLength": 2000,
+      "type": "string"
+    },
+    "source": {
+      "maxLength": 1000,
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
```
  - addedInput schema / properties / services / items / properties / files_referencing / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / replacement_validation
```
Added value: +{
+  "additionalProperties": false,
+  "description": "A replacement path the user checked themselves: its current price, capacity, burst limits and paid add-ons against their usage. It answers that path's capacity checks (never its must-haves) and ranks it first",
+  "properties": {
+    "capacity_and_price_confirmed": {
+      "description": "true only after checking the price, capacity, burst limits and required add-ons",
+      "type": "boolean"
+    },
+    "path_id": {
+      "description": "The path id (from find_alternatives or audit_stack)",
+      "maxLength": 200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "source": {
+      "description": "Where the check comes from (usage report, pricing page, quote); no private contents",
+      "maxLength": 1000,
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "path_id",
+    "capacity_and_price_confirmed",
+    "source"
+  ],
+  "type": "object"
+}
```
  - addedInput schema / properties / services / items / properties / service_id
```
Added value: +{
+  "description": "A distinct bill when the same vendor appears more than once (an account key, like account; lines with the same key are one bill)",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
```
  - addedInput schema / properties / services / items / properties / usage / properties / MAU / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / active_accounts / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / apps / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / audio_minutes_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / bandwidth_gb / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / browser_hours_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / cache_commands_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / cached_tokens_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / call_participants / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / characters_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / concurrent_sessions / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / contacts / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / cpu_ms_per_request / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / credits_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / credits_usd_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / db_gb / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / disputes_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / domains / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / emails_per_day / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / emails_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / errors_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / event_types / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / events_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / files / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / gmv_usd_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / gpu_seconds_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / history_days / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / images_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / inbound_emails_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / inboxes / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / job_executions_per_day / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / job_executions_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / keywords_tracked / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / mau / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / meeting_minutes / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / members / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / monitors / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / mtu / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / object_reads_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / object_writes_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / pageviews_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / payout_volume_usd_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / payouts_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / phone_minutes_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / projects / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / proxy_gb_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / records / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / requests_per_day / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / requests_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / responses_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / revenue_usd_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / sandbox_hours_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / scim_connections / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / searches_per_hour / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / searches_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / seats / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / session_minutes / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / sites / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / sms_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / sso_connections / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / sso_users / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / storage_gb / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / stream_hours_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / tasks_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / tokens_in_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / tokens_out_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / tokens_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / transactions_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / vcpu_hours_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / vector_queries_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / vector_read_units_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / vector_write_units_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / vectors_stored / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / verifications_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / video_minutes / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / video_minutes_delivered_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / video_minutes_stored / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / services / items / properties / usage / properties / videos / maximum
```
Added value: +1000000000000
```
- Changedchoose_stack8 fields changed
  - addedInput schema / properties / budget_monthly_usd / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / needs / items / properties / peak_volume
```
Added value: +{
+  "additionalProperties": false,
+  "description": "Peak or burst requirement (1.6.0), e.g. {amount: 1500, unit: 'emails_per_day'} for a launch day. Checked against a tier's published daily cap where the index has one; otherwise it stays an open check (the index doesn't prove burst or rate limits), so no option is a plain fit",
+  "properties": {
+    "amount": {
+      "maximum": 1000000000000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "unit": {
+      "enum": [
+        "emails_per_day",
+        "requests_per_day",
+        "requests_per_second"
+      ],
+      "maxLength": 2000,
+      "type": "string"
+    }
+  },
+  "required": [
+    "amount",
+    "unit"
+  ],
+  "type": "object"
+}
```
  - addedInput schema / properties / needs / items / properties / per_user / items / properties / unit / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / needs / items / properties / volume / properties / unit / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / needs / items / properties / volumes / items / properties / unit / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / prefer / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / scale_by / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / unit_economics / properties / billing / maxLength
```
Added value: +2000
```
- Changedfind_alternatives80 fields changed
  - addedInput schema / properties / billing
```
Added value: +{
+  "additionalProperties": false,
+  "description": "Billing evidence: scope (dedicated, shared or unknown), account_id (a non-secret alias; the account key), allocated_monthly_usd (attribution only, never a saving), avoidable_monthly_usd with avoidability_confirmed (what leaving actually removes from the bill; 0 is valid), commitment_months_remaining (non-refundable months left; 0 only when cancellable now) and source (a reference, no private contents). With billing, a path is eligible only once the avoidable amount, scope, commitment and source are all given",
+  "properties": {
+    "account_id": {
+      "maxLength": 200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "allocated_monthly_usd": {
+      "maximum": 1000000000000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "avoidability_confirmed": {
+      "type": "boolean"
+    },
+    "avoidable_monthly_usd": {
+      "maximum": 1000000000000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "commitment_months_remaining": {
+      "maximum": 120,
+      "minimum": 0,
+      "type": "number"
+    },
+    "scope": {
+      "enum": [
+        "dedicated",
+        "shared",
+        "unknown"
+      ],
+      "maxLength": 2000,
+      "type": "string"
+    },
+    "source": {
+      "maxLength": 1000,
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
```
  - addedInput schema / properties / replacement_validation
```
Added value: +{
+  "additionalProperties": false,
+  "description": "A replacement path the user checked themselves: its current price, capacity, burst limits and paid add-ons against their usage. It answers that path's capacity checks (never its must-haves) and ranks it first",
+  "properties": {
+    "capacity_and_price_confirmed": {
+      "description": "true only after checking the price, capacity, burst limits and required add-ons",
+      "type": "boolean"
+    },
+    "path_id": {
+      "description": "The path id (from find_alternatives or audit_stack)",
+      "maxLength": 200,
+      "minLength": 1,
+      "type": "string"
+    },
+    "source": {
+      "description": "Where the check comes from (usage report, pricing page, quote); no private contents",
+      "maxLength": 1000,
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "path_id",
+    "capacity_and_price_confirmed",
+    "source"
+  ],
+  "type": "object"
+}
```
  - addedInput schema / properties / usage / properties / MAU / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / active_accounts / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / apps / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / audio_minutes_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / bandwidth_gb / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / browser_hours_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / cache_commands_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / cached_tokens_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / call_participants / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / characters_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / concurrent_sessions / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / contacts / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / cpu_ms_per_request / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / credits_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / credits_usd_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / db_gb / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / disputes_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / domains / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / emails_per_day / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / emails_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / errors_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / event_types / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / events_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / files / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / gmv_usd_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / gpu_seconds_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / history_days / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / images_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / inbound_emails_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / inboxes / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / job_executions_per_day / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / job_executions_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / keywords_tracked / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / mau / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / meeting_minutes / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / members / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / monitors / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / mtu / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / object_reads_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / object_writes_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / pageviews_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / payout_volume_usd_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / payouts_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / phone_minutes_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / projects / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / proxy_gb_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / records / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / requests_per_day / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / requests_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / responses_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / revenue_usd_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / sandbox_hours_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / scim_connections / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / searches_per_hour / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / searches_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / seats / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / session_minutes / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / sites / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / sms_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / sso_connections / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / sso_users / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / storage_gb / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / stream_hours_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / tasks_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / tokens_in_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / tokens_out_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / tokens_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / transactions_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / vcpu_hours_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / vector_queries_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / vector_read_units_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / vector_write_units_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / vectors_stored / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / verifications_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / video_minutes / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / video_minutes_delivered_per_month / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / video_minutes_stored / maximum
```
Added value: +1000000000000
```
  - addedInput schema / properties / usage / properties / videos / maximum
```
Added value: +1000000000000
```
- Addedget_workflow_recipe
- Changedleaderboard2 fields changed
  - addedInput schema / properties / metric / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / path_type / maxLength
```
Added value: +2000
```
- Changedplan_stack_from_spec4 fields changed
  - addedInput schema / properties / overrides / items / properties / basis / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / overrides / items / properties / unit / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / prefer / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / unit_economics / properties / billing / maxLength
```
Added value: +2000
```
- Changedreport_outcome1 field changed
  - addedInput schema / properties / outcome / maxLength
```
Added value: +2000
```
- Changedsearch_recipes2 fields changed
  - addedInput schema / properties / path_type / maxLength
```
Added value: +2000
```
  - addedInput schema / properties / sort / maxLength
```
Added value: +2000
```
- Addedsearch_workflow_recipes
- Addedstart_audit

4 tool updatesSep 26, 2026

Changedaudit_stack23 fields changed

addedInput schema / properties / active_users

Added value: +{
+  "description": "People or accounts active in the last 30 days (0 = unused: cleanup levers and sanity checks)",
+  "maximum": 1000000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / revenue_usd_per_month

Added value: +{
+  "description": "The product's revenue per month (context for sanity checks: no revenue, cost per user, fees vs revenue; never a cap)",
+  "maximum": 1000000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / services / items / properties / account

Added value: +{
+  "description": "Billing account key (e.g. 'supabase-org-main'): lines with the same vendor and key share one bill; different keys are separate bills. Give the bill once",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / services / items / properties / active_users

Added value: +{
+  "description": "People or accounts active in the last 30 days (0 = unused: cleanup levers and sanity checks)",
+  "maximum": 1000000000,
+  "minimum": 0,
+  "type": "number"
+}

changedInput schema / properties / services / items / properties / confidence / description

Previous value: -"detect.mjs output (ignored)"New value: +"detect.mjs output: 'low' (only a config file) means no paid plan is assumed"

addedInput schema / properties / services / items / properties / confirmed

Added value: +{
+  "description": "true when the user confirmed they pay for this (with plan: its list price counts as confirmed spend). Scanner-only lines are unconfirmed",
+  "type": "boolean"
+}

changedInput schema / properties / services / items / properties / files_referencing / description

Previous value: -"detect.mjs output (ignored)"New value: +"detect.mjs output: marks the line as scan-only (unconfirmed); never read as usage"

addedInput schema / properties / services / items / properties / last_active

Added value: +{
+  "description": "When this resource (project, app, account) was last used: an ISO date ('2026-03-10'), 'never', or '5 months ago'. 90+ days idle or never used gets a cleanup lever",
+  "maxLength": 100,
+  "type": "string"
+}

addedInput schema / properties / services / items / properties / revenue_usd_per_month

Added value: +{
+  "description": "The product's revenue per month (context for sanity checks: no revenue, cost per user, fees vs revenue; never a cap)",
+  "maximum": 1000000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / services / items / properties / shared_with

Added value: +{
+  "description": "How many products share this bill (one account, org or team), when only this product is audited: moving one product off it saves only what it adds to the bill, never the whole bill. monthly_spend_usd is then the whole account's bill",
+  "maximum": 100000,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / services / items / properties / usage / description

Previous value: -"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."New value: +"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."

addedInput schema / properties / services / items / properties / usage / properties / cache_commands_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / gpu_seconds_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / mtu
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / phone_minutes_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / revenue_usd_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / searches_per_hour
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / sms_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / vector_queries_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / vector_read_units_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / vector_write_units_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / services / items / properties / usage / properties / vectors_stored
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
changedInput schema / properties / services / maxItems
```
Previous value: -60New value: +200
```

Changedchoose_stack3 fields changed

changedInput schema / properties / needs / items / properties / per_user / items / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

changedInput schema / properties / needs / items / properties / volume / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

changedInput schema / properties / needs / items / properties / volumes / items / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

Changedfind_alternatives18 fields changed

addedInput schema / properties / active_users

Added value: +{
+  "description": "People or accounts active in the last 30 days (0 = unused: cleanup levers and sanity checks)",
+  "maximum": 1000000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / confirmed

Added value: +{
+  "description": "true when the user confirmed they pay for this (with plan: its list price counts as confirmed spend). Scanner-only lines are unconfirmed",
+  "type": "boolean"
+}

changedInput schema / properties / evidence / description

Previous value: -"Usage facts in words, read best effort: 'db 1.5 GB', '40,000 emails/mo', '37 domains', '3,000 MAU'"New value: +"Usage facts in words, read best effort: 'db 1.5 GB', '40,000 emails/mo', '37 domains', '3,000 MAU', 'shared by 40 projects'"

addedInput schema / properties / last_active

Added value: +{
+  "description": "When this resource (project, app, account) was last used: an ISO date ('2026-03-10'), 'never', or '5 months ago'. 90+ days idle or never used gets a cleanup lever",
+  "maxLength": 100,
+  "type": "string"
+}

addedInput schema / properties / revenue_usd_per_month

Added value: +{
+  "description": "The product's revenue per month (context for sanity checks: no revenue, cost per user, fees vs revenue; never a cap)",
+  "maximum": 1000000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / shared_with

Added value: +{
+  "description": "How many products share this bill (one account, org or team), when only this product is audited: moving one product off it saves only what it adds to the bill, never the whole bill. monthly_spend_usd is then the whole account's bill",
+  "maximum": 100000,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / usage / description

Previous value: -"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."New value: +"Their usage, checked against each plan's caps (priced with published overage and add-ons). Units: seats, members, mau, emails_per_month, emails_per_day, contacts, domains, events_per_month, pageviews_per_month, errors_per_month, requests_per_month, requests_per_day, searches_per_month, cpu_ms_per_request, db_gb, storage_gb, bandwidth_gb, projects, sites, videos, video_minutes, responses_per_month, tasks_per_month, keywords_tracked, credits_per_month, history_days, apps, files, event_types, monitors, tokens_per_month, images_per_month, audio_minutes_per_month, characters_per_month, transactions_per_month, sandbox_hours_per_month, concurrent_sessions, session_minutes, call_participants, meeting_minutes, records, inboxes, tokens_in_per_month, tokens_out_per_month, cached_tokens_per_month, video_minutes_stored, video_minutes_delivered_per_month, gmv_usd_per_month, payouts_per_month, active_accounts, verifications_per_month, browser_hours_per_month, proxy_gb_per_month, job_executions_per_month, sso_connections, sso_users, inbound_emails_per_month, stream_hours_per_month, vcpu_hours_per_month, credits_usd_per_month, disputes_per_month, payout_volume_usd_per_month, object_writes_per_month, object_reads_per_month, job_executions_per_day, scim_connections, searches_per_hour, sms_per_month, vectors_stored, vector_queries_per_month, cache_commands_per_month, mtu, gpu_seconds_per_month, revenue_usd_per_month, phone_minutes_per_month, vector_read_units_per_month, vector_write_units_per_month (MAU is accepted for mau). Example: {\"emails_per_month\": 40000, \"domains\": 4, \"db_gb\": 3}. get_usage_questions says which units matter for a vendor and where the user finds each number."

addedInput schema / properties / usage / properties / cache_commands_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / usage / properties / gpu_seconds_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```

addedInput schema / properties / usage / properties / mtu

Added value: +{
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / usage / properties / phone_minutes_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / usage / properties / revenue_usd_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / usage / properties / searches_per_hour
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / usage / properties / sms_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / usage / properties / vector_queries_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / usage / properties / vector_read_units_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / usage / properties / vector_write_units_per_month
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / usage / properties / vectors_stored
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```

Changedplan_stack_from_spec1 field changed

changedInput schema / properties / overrides / items / properties / unit / enum

Previous value: -[
-  "seats",
-  "members",
-  "mau",
-  "emails_per_month",
-  "emails_per_day",
-  "contacts",
-  "domains",
-  "events_per_month",
-  "pageviews_per_month",
-  "errors_per_month",
-  "requests_per_month",
-  "requests_per_day",
-  "searches_per_month",
-  "cpu_ms_per_request",
-  "db_gb",
-  "storage_gb",
-  "bandwidth_gb",
-  "projects",
-  "sites",
-  "videos",
-  "video_minutes",
-  "responses_per_month",
-  "tasks_per_month",
-  "keywords_tracked",
-  "credits_per_month",
-  "history_days",
-  "apps",
-  "files",
-  "event_types",
-  "monitors",
-  "tokens_per_month",
-  "images_per_month",
-  "audio_minutes_per_month",
-  "characters_per_month",
-  "transactions_per_month",
-  "sandbox_hours_per_month",
-  "concurrent_sessions",
-  "session_minutes",
-  "call_participants",
-  "meeting_minutes",
-  "records",
-  "inboxes",
-  "tokens_in_per_month",
-  "tokens_out_per_month",
-  "cached_tokens_per_month",
-  "video_minutes_stored",
-  "video_minutes_delivered_per_month",
-  "gmv_usd_per_month",
-  "payouts_per_month",
-  "active_accounts",
-  "verifications_per_month",
-  "browser_hours_per_month",
-  "proxy_gb_per_month",
-  "job_executions_per_month",
-  "sso_connections",
-  "sso_users",
-  "inbound_emails_per_month",
-  "stream_hours_per_month",
-  "vcpu_hours_per_month",
-  "credits_usd_per_month",
-  "disputes_per_month",
-  "payout_volume_usd_per_month",
-  "object_writes_per_month",
-  "object_reads_per_month",
-  "job_executions_per_day",
-  "scim_connections",
-  "MAU",
-  "tokens",
-  "tokens_in",
-  "tokens_out",
-  "cached_tokens",
-  "images",
-  "video_minutes_delivered",
-  "gb_stored",
-  "gb_egress",
-  "transactions",
-  "gmv_usd",
-  "sandbox_seconds",
-  "sandbox_hours",
-  "vm_hours",
-  "vcpu_hours",
-  "browser_hours",
-  "proxy_gb",
-  "job_executions",
-  "verifications",
-  "inbound_emails",
-  "emails",
-  "events",
-  "errors",
-  "exceptions",
-  "requests",
-  "pageviews",
-  "searches",
-  "payouts",
-  "credits_usd",
-  "stream_hours",
-  "audio_minutes",
-  "characters",
-  "payout_volume_usd",
-  "disputes",
-  "object_writes",
-  "object_reads"
-]New value: +[
+  "seats",
+  "members",
+  "mau",
+  "emails_per_month",
+  "emails_per_day",
+  "contacts",
+  "domains",
+  "events_per_month",
+  "pageviews_per_month",
+  "errors_per_month",
+  "requests_per_month",
+  "requests_per_day",
+  "searches_per_month",
+  "cpu_ms_per_request",
+  "db_gb",
+  "storage_gb",
+  "bandwidth_gb",
+  "projects",
+  "sites",
+  "videos",
+  "video_minutes",
+  "responses_per_month",
+  "tasks_per_month",
+  "keywords_tracked",
+  "credits_per_month",
+  "history_days",
+  "apps",
+  "files",
+  "event_types",
+  "monitors",
+  "tokens_per_month",
+  "images_per_month",
+  "audio_minutes_per_month",
+  "characters_per_month",
+  "transactions_per_month",
+  "sandbox_hours_per_month",
+  "concurrent_sessions",
+  "session_minutes",
+  "call_participants",
+  "meeting_minutes",
+  "records",
+  "inboxes",
+  "tokens_in_per_month",
+  "tokens_out_per_month",
+  "cached_tokens_per_month",
+  "video_minutes_stored",
+  "video_minutes_delivered_per_month",
+  "gmv_usd_per_month",
+  "payouts_per_month",
+  "active_accounts",
+  "verifications_per_month",
+  "browser_hours_per_month",
+  "proxy_gb_per_month",
+  "job_executions_per_month",
+  "sso_connections",
+  "sso_users",
+  "inbound_emails_per_month",
+  "stream_hours_per_month",
+  "vcpu_hours_per_month",
+  "credits_usd_per_month",
+  "disputes_per_month",
+  "payout_volume_usd_per_month",
+  "object_writes_per_month",
+  "object_reads_per_month",
+  "job_executions_per_day",
+  "scim_connections",
+  "searches_per_hour",
+  "sms_per_month",
+  "vectors_stored",
+  "vector_queries_per_month",
+  "cache_commands_per_month",
+  "mtu",
+  "gpu_seconds_per_month",
+  "revenue_usd_per_month",
+  "phone_minutes_per_month",
+  "vector_read_units_per_month",
+  "vector_write_units_per_month",
+  "MAU",
+  "tokens",
+  "tokens_in",
+  "tokens_out",
+  "cached_tokens",
+  "images",
+  "video_minutes_delivered",
+  "gb_stored",
+  "gb_egress",
+  "transactions",
+  "gmv_usd",
+  "sandbox_seconds",
+  "sandbox_hours",
+  "vm_hours",
+  "vcpu_hours",
+  "browser_hours",
+  "proxy_gb",
+  "job_executions",
+  "verifications",
+  "inbound_emails",
+  "emails",
+  "events",
+  "errors",
+  "exceptions",
+  "requests",
+  "pageviews",
+  "searches",
+  "payouts",
+  "credits_usd",
+  "stream_hours",
+  "audio_minutes",
+  "characters",
+  "payout_volume_usd",
+  "disputes",
+  "object_writes",
+  "object_reads",
+  "sms",
+  "vectors",
+  "vector_queries",
+  "cache_commands",
+  "gpu_seconds",
+  "gpu_hours",
+  "revenue_usd",
+  "phone_minutes"
+]

Related MCP Connectors

OneLessTool A
com.onelesstool
Find software subscriptions you can drop using tools you already own, with vendor-verified prices.
Finance Product Management
91
https://onelesstool.com/api/mcp
Postbye A
com.postbye
Read-only cancellation guides, mailing addresses and letters for thousands of subscriptions.
41
https://postbye.com/mcp
AIBuilder Marketplace: software pricing dossiers B
com.aibuildermarketplace
Dated plan prices, cost traps with evidence and hands-on results for 540 business-software tools.
Research & Data Finance E-commerce & Retail
151
https://api.aibuildermarketplace.com/mcp
stackledger A
com.edgethirteen.www
Audit a pasted SaaS subscription list for redundant-category overlap and overspend.
Finance
1
https://www.edgethirteen.com/api/mcp/stackledger

Related MCP Servers

zombie-killer
Finance Legal & Compliance App Automation
Baneado98
A
license
A
quality
D
maintenance
Scans bank statements for zombie subscriptions and drafts cancellation, renegotiation, or data deletion letters.
Updated 4 months ago (2026-06-22 18:20 UTC)
3
MIT
genpark-personal-agentofficial
Finance Payments & Billing
Alpha-Park
F
license
Not graded
quality
B
maintenance
Enables users to audit recurring bank/card subscription charges, detect sneaky fee increases or expired-trial conversions, calculate annualized budget leakage, and generate retention negotiation dispute letters.
Updated 9 days ago (2026-10-18 07:48 UTC)
7
-
Subscription Tracker Ai
Finance Payments & Billing
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
Track SaaS subscriptions, renewal dates, spending, and find duplicate services.
Updated 19 days ago (2026-10-08 04:25 UTC)
2 npm
52 PyPI
MIT
genpark-personal-agentofficial
Finance Payments & Billing
alphaparkinc
F
license
Not graded
quality
B
maintenance
Enables auditing recurring bank and card subscription charges to detect stealth price increases, expired trial conversions, and calculate annualized budget leakage. It also generates retention negotiation dispute letters to help users reduce unnecessary expenses.
Updated 9 days ago (2026-10-18 07:47 UTC)
7
-