A
licenseNot graded
qualityB
maintenanceTrack SaaS subscriptions, renewal dates, spending, and find duplicate services.
6 npm
MIT
Stackcut
by io.stackcut
Server Details
Cut SaaS spend: checked savings, right-sized plans, alternatives, runbooks, 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
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- Stackcut/stackcut-plugin
- GitHub Stars
- 0
TDQS
B3.4/5.0
Scored across 20 tools
Disambiguation4/5
Most tools are clearly scoped: search/detail pairs (search_recipes vs get_recipe, search_exits vs get_exit_plan) and workflow/catalog tools are distinct. There is some overlap between start_audit and audit_stack, and between find_alternatives and search_recipes, but the descriptions usually make the intended use clear.
Naming Consistency4/5
The set uses consistent snake_case and mostly verb_noun or verb_phrase patterns (get_, list_, search_, report_, choose_, plan_). The main deviation is the bare noun leaderboard, plus a few longer names, but overall naming is predictable.
Tool Count3/5
20 tools is heavy for an MCP server and sits in the borderline 16-25 range. The broad Stackcut domain justifies several sub-areas, but multiple entry points and search/detail pairs make the surface feel larger than necessary.
Completeness5/5
The tools cover the full lifecycle: audit preparation and execution, vendor selection, alternatives and recipes, cancellation, workflow migrations, build packets, personal plans, and outcome reporting. There are no obvious dead ends for the stated SaaS cost-optimization purpose.
Available Tools
20 toolsaudit_stackAudit a stack (code + billing)ARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the readOnly/idempotent annotations: output statuses and their meanings, price handling, levers not counted as savings, and detailed data-retention/privacy behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place: use case first, then input structure, output behavior, workflow advice, and privacy/storage. It is front-loaded with the selection trigger and contains no filler.
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?
Despite having no output schema, it describes the per-service result categories (status, best path, right_size, overlaps, levers) and how missing facts are routed. The main gap is the unmentioned limit_paths parameter and the absence of an exact output envelope.
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?
The description usefully explains how to structure the services array (vendor, plan, seats, usage, project, account) and imposes privacy constraints on values. However, with 50% schema coverage it does not compensate fully: limit_paths is never mentioned, and top-level active_users/revenue_usd_per_month are only covered by schema descriptions.
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 resource: auditing a whole stack, with concrete user intents ('audit what we pay for', 'what can we cut?') and portfolio/billing scopes. It also distinguishes itself from start_audit by noting that missing facts are handled there.
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 'Use when' trigger with examples of what counts as a whole-stack audit. It names start_audit as the place that prioritizes missing facts, but does not explicitly exclude other siblings like find_alternatives or choose_stack.
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 stackARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| 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.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context beyond this: data-retention practices (which arguments are stored, one-way hashing of account keys, never IP addresses), the 'total keeps proven, estimated and unpriced jobs apart' output semantics, the fit criteria, and the 120-day price-check rule. This is rich, non-redundant disclosure.
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 dense and front-loaded with the usage trigger and examples before diving into mechanics. It is long, and the privacy sentence at the end is verbose, but nearly every sentence carries load-bearing information (fit rules, scale semantics, storage policy, sibling routing). It would earn a 5 with tighter paragraphing.
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 tool with 8 parameters, nested objects, and no output schema, the description covers the critical ground: when to invoke, fit verification, scale/budget behavior, data privacy, and alternative tools. It does not describe the returned structure (the 'total' categories are mentioned but not fully specified), and features/per_user semantics are left to the schema, which is acceptable.
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 63%, so the description must partially compensate, and it does: it explains that scales are MAU for cost curves and break-evens, that the smallest scale becomes the priced MAU when no MAU appears elsewhere, and that budget_monthly_usd tests a budget. It does not mention limit_per_job, but the schema already documents most other parameters well and the added semantics target the trickiest params.
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 opens with a specific verb-resource pairing ('picking vendors for something they're building') and grounds it with concrete examples ('cheapest database for 20k users', 'Resend or Postmark at 60,000 emails a month?'). It also explicitly names the closest sibling (plan_stack_from_spec) and what that sibling is for, so an agent can distinguish 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?
It states exactly when to use the tool ('when the user is picking vendors') and routes the whole-product-brief case to plan_stack_from_spec. It also explains the fit verification semantics (published caps, must-haves, 120-day price freshness) and how uncertain cases are handled ('comes back as a check or a question'), leaving no ambiguity about when a result is a firm recommendation.
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 subscriptionARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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, 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. | |
| 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.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint, idempotentHint, and destructiveHint annotations, the description adds substantial behavioral context: it explains the meaning of fit vs check, instructs that 'ask its questions before recommending it', describes savings as modeled from public list prices, and discloses data storage practices ('Stackcut stores the arguments of tool calls... never IP addresses'). This goes well beyond the annotations and does not contradict them.
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 'Use when' trigger, followed by parameter guidance, return semantics, savings modeling, and data privacy. Each sentence has a distinct purpose; however, the privacy sentence is quite long and packs many details, making it slightly heavier than necessary. Overall it is dense but well organized for a tool with 15 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?
The description covers the core invocation flow, including what to pass, what the tool returns (ranked paths, fit/check/status/why/questions), how to handle open-check paths, savings assumptions, and data handling. It does not mention optional parameters like billing, shared_with, or replacement_validation, but those are adequately described in the schema and are not essential to the primary use case. The absence of an output schema is partially offset by the detailed explanation of result semantics.
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 input schema already covers 93% of parameters, so the baseline is 3. The description adds value by giving extraction guidance: it maps natural-language user statements to specific parameters ('Pass what they pay (monthly_spend_usd), seats, the features they use and their usage (usage, or evidence such as '40,000 emails/mo')'). This is a meaningful layer beyond the schema's per-field descriptions, though it does not discuss every optional parameter.
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 and resource: '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.' It further clarifies scope by describing the return, 'ranked paths re-costed at their price, including a cheaper plan of the same vendor (right_size).' This distinguishes it from siblings like audit_stack and search_recipes by naming the trigger condition and output.
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 description gives an explicit trigger ('Use when the user names one product they pay for...') and tells the agent which parameters to populate ('Pass what they pay (monthly_spend_usd), seats, the features they use and their usage (usage, or evidence such as '40,000 emails/mo')'). It also references the sibling tool get_usage_questions for determining which usage units matter. However, it does not explicitly state when not to use this tool or name exclusion criteria relative to alternatives.
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)ARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | Yes |
TDQS
A3.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly, idempotent, and non-destructive annotations, the description discloses data-retention behavior: Stackcut stores tool-call arguments, hashes account keys, never stores IP addresses, and warns against sending personal data or secrets. This is valuable behavioral context not present in 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 use case and outputs, then adds a privacy notice. The privacy sentence is long but relevant; there is no filler, though it could be tightened without losing meaning.
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?
It covers outputs, fallback behavior, and privacy constraints, while annotations cover the safety profile. The main gaps are explicit recipe_id semantics and a detailed return structure, but for a single-parameter read-only tool it is largely complete.
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%, and the description never names recipe_id or explains how to supply it. It only implies the tool operates on a recipe, which is insufficient for a required parameter with no schema-level documentation.
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 clearly states what the tool does: returns SPEC.md, AGENTS.md, and runbook files for recipes with a build path, and assessment files for recipes without one. It is tied to the 'Replace with AI' use case, but it does not explicitly name or differentiate sibling tools like 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It opens with 'Use when the user wants to replace a tool by building their own' and instructs the agent to check packet_kind and next_step before acting. However, it does not mention alternatives or exclusion conditions, so it stops short of full routing guidance.
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 rulesARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| vendors | No | Only these vendors, by id or name (default: all) |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds context beyond that: it clarifies the tool returns rules (not actual scanning), and it includes a detailed privacy disclosure about how arguments are stored (hashed keys, no IPs, no personal data). This provides meaningful behavioral transparency that the annotations alone do not cover.
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 longer than ideal but well-structured: purpose first, then usage guidance, then privacy. The privacy paragraph is necessary given the tool's context, though it could be condensed. The key operational instructions are front-loaded and clear, so it earns a 4 for structure despite verbosity.
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?
The tool has no output schema, so the description carries the burden of explaining what is returned. It explains the rules' nature, how to apply them, what to send to audit_stack, and the 'unknown' fallback. This is sufficient for an agent to use the tool correctly; the only minor gap is lack of detail on the exact format of returned rules, but that is not critical for invocation.
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 100% – the single 'vendors' parameter is documented as 'Only these vendors, by id or name (default: all).' The description does not add substantial parameter-level detail, but it reinforces the concept of vendor names and the ~100 vendor count. Baseline of 3 is appropriate given the schema already covers the parameter.
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 opens with a specific statement of what the tool does: provides detection rules for paid services (package names, env var patterns, config files, API hosts, feature patterns for ~100 vendors). This is a clear verb+resource with concrete scope, and it distinguishes itself from sibling tools by describing the local application and the audit_stack output target.
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 description gives explicit usage direction: apply rules locally and send only vendor/feature names to audit_stack, never code or secret values. It also notes that names without rules come back under 'unknown.' While it doesn't explicitly compare to alternatives, the workflow guidance is concrete and actionable.
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 subscriptionARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | The subscription, e.g. 'YouTube TV', 'Adobe Creative Cloud', 'disneyplus.com' | |
| billed_by | No | 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 | |
| renewal_date | No | Next renewal date, YYYY-MM-DD: adds the last safe day to cancel from the documented notice period |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/idempotent safety profile; the description adds substantial context beyond them: the exact shape of the return, source citation with check dates, the requirement that the user signs in and confirms, and an explicit data-handling disclosure about what is stored from tool-call arguments. This is rich behavioral disclosure the annotations cannot 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-loaded with the usage trigger and dense with signal, but the final privacy/data-retention sentence is long and parenthetically overloaded, diluting the block. Every sentence does earn its place, so only mild trimming is warranted.
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 carries the return-value burden and does so thoroughly, listing each element of the exit plan. Combined with the privacy note, the consent constraint, and the optional billing/renewal inputs, an agent has everything needed to call and set expectations.
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 genuine meaning: billed_by is tied to 'the name on their card statement or receipt' and renewal_date is framed as yielding 'the last safe day to cancel'. That is semantic value beyond the schema's own descriptions.
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 (retrieve an exit plan for a named subscription) and enumerates the returned content in detail: cancel routes by biller, steps, notice periods, fees, refunds, export list. That scope statement is precise enough to separate it from siblings like search_exits or audit_stack without opening a 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?
Strong when-to-use trigger set with concrete example utterances ('cancel YouTube TV', 'how do I get out of Adobe') plus a hard behavioral constraint ('Never cancel for the user without their go-ahead'). However, it never names an alternative tool or a when-not condition, so the agent gets context but no explicit routing against siblings.
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 planARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The agent code from stackcut.io, e.g. sca_… |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly/idempotent/non-destructive; the description adds that the code expires, is read-only, and discloses how tool-call arguments are stored. This is valuable context beyond the annotations and contains 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?
The description is longer than average but each sentence earns its place: trigger condition, returned plan contents, interaction guidance, and privacy warning are clearly separated. It is front-loaded with the most important usage rule.
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?
For a one-parameter read-only tool, the description fully covers when to call it, what it returns, how to behave with the results, and privacy constraints. No output schema is needed because the return contents are enumerated clearly.
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% for the single code parameter. The description adds value beyond the schema by explaining the code's prefix (sca_), where the user obtains it, its read-only/expiring nature, and that personal data or secrets must not be sent.
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 names a specific verb and resource: retrieve the user's own Stackcut savings plan from an agent code. It also states the precise trigger ('only when the user gives you a Stackcut agent code'), which distinguishes it from recipe/build/plan siblings.
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?
Explicitly says when to use: only when the user provides a sca_ code copied from 'Send to my agent'. It also gives follow-up guidance (walk through from biggest saving, ask before cancelling/purchasing) and warns not to send secrets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recipeGet a recipeARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recipe id from search_recipes, e.g. 'crm-pipeline' |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds important behavioral context beyond that: Stackcut stores tool-call arguments to improve recommendations, hashes account keys, never stores IP addresses, and distinguishes Stackcut lab results from customer results. No annotation contradiction exists.
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 purpose is front-loaded and the first sentence efficiently enumerates the rich set of return content. However, the privacy/data-retention disclosure is long and parenthetical, stretching one idea into a dense block that is harder to parse than necessary.
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 full burden of explaining what the tool returns, and it does so thoroughly: savings, costs, setup, out-of-scope items, pre-switch checks, cancellation steps, playbooks, sources, and lab results. It also covers data-handling expectations and what not to send, making the definition complete for a fetch-by-id tool.
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%: the single required id parameter is fully documented with an explanation and example ('Recipe id from search_recipes, e.g. 'crm-pipeline''). The description reinforces that the id comes from search_recipes but adds no new format, constraints, or syntax beyond the schema, so 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?
The description states a specific verb and resource: 'Full detail for one recipe from search_recipes,' with an explicit list of what the detail includes. This distinguishes it from search_recipes and the sibling get_workflow_recipe, so an agent can tell them apart 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from search_recipes' implies the correct workflow: first search, then fetch a recipe's full detail. It also warns 'don't send personal data or secrets,' which is a practical usage constraint. It stops short of explicitly naming alternatives or giving when-not-to-use conditions, so it is clear but not fully explicit.
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 vendorsARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| 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.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, non-destructive behavior, so the description adds important extra context: units in context are marked as given, and there is a detailed privacy disclosure about what Stackcut stores, hashes, never stores, and a warning not to send personal data or secrets.
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 core purpose and every sentence carries useful information. The main weakness is structural: the privacy notice is one long, dense embedded clause that could be clearer as a separate sentence or list, though nothing is wasted.
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?
Despite having no output schema, the description explains what the tool returns: relevant usage numbers, where to find them, and ready-to-ask questions. It also covers handling of context units and how to route results to downstream tools, making the definition complete for an agent.
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 both parameters already described with examples and constraints. The description reinforces the behavior of the context parameter ('Units already stated in context are marked as given') but adds no new parameter-level semantics beyond the schema, so the baseline of 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?
The description clearly defines what the tool does: before an audit, it generates which usage numbers matter for each vendor, where to find them, and ready-to-ask questions. It also distinguishes itself from siblings by placing itself as a pre-audit step that feeds audit_stack or find_alternatives.
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?
'Before an audit' provides clear usage context, and 'Pass the answers to audit_stack or find_alternatives' names the downstream alternatives. However, it does not explicitly state when to choose one downstream tool over the other, so it stops short of full when-to-use/when-not guidance.
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 recipeARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow id from search_workflow_recipes, e.g. 'portfolio-shared-billing' |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (readOnlyHint, idempotentHint) by revealing data storage practices (Stackcut stores call arguments, hashes account keys, never stores IPs), a privacy warning ('don't send personal data or secrets'), and a semantic caveat ('A reviewed playbook is not a completed customer migration'). These are behavioral details that the annotations do not cover, and they do not contradict the declared hints.
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 lengthy but well-structured: it front-loads the core purpose with a colon, then lists deliverables, adds a cautionary note, and concludes with privacy guidelines. Every sentence earns its place, though it is slightly verbose. It is appropriately sized for the complexity of a workflow-recipe 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?
For a single-parameter tool with no output schema, the description is remarkably complete: it lists what the runbook will contain (evidence, decisions, steps, tests, rollout, rollback, maintenance, templates, digest), warns about interpretation, and explains data handling. An agent can confidently invoke the tool and understand what to expect in the response without needing additional documentation.
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% – the id parameter already specifies it comes from search_workflow_recipes with an example. The description restates this source but adds no new meaning beyond the schema. Baseline of 3 is appropriate since the schema fully documents the parameter and the description adds nothing substantive.
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 clearly identifies the tool as retrieving a full workflow recipe ('One runbook from search_workflow_recipes in full'), distinguishes it from the generic get_recipe by specifying the source, and enumerates the exact contents of the returned runbook (evidence, decisions, steps, tests, etc.). The verb 'get' plus the specific resource and the explicit source make 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?
The description implies usage context by stating the recipe comes from search_workflow_recipes and the parameter description repeats the source, making it clear this tool follows a search. However, it does not explicitly exclude alternatives (like get_build_packet) or provide a when-not-to-use clause. The context is clear but lacks explicit routing or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leaderboardSavings leaderboardCRead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| metric | No | savings | |
| category | No | ||
| path_type | No | ||
| include_partial | No |
TDQS
C2.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable behavioral details: it excludes partial replacements unless include_partial, and never lists trials, one-time credits, expiring or non-commercial plans. It also includes a privacy disclosure about how arguments are stored, which goes beyond the annotations. These are meaningful additions beyond the structured hints.
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 first sentence is concise and informative, but the second sentence is a long, boilerplate privacy notice that is tangentially related to the tool's operation. It spans several clauses and distracts from the core purpose. The description is not front-loaded; the key info is in the first sentence, but the excess text makes it less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a read-only query tool with 5 optional parameters and no output schema. The description only explains the filtering behavior and the privacy policy, but does not describe the parameters or the expected return format. An agent would need to infer parameter meanings from the schema alone, which is insufficient. The privacy disclosure, while important, is not directly about the tool's usage. Overall, the description is incomplete for a tool with this parameter complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any parameters except mentioning 'include_partial' by name. The schema itself has 5 parameters (limit, metric, category, path_type, include_partial) with enums and defaults, but the description adds no semantic meaning to these parameters. For example, it doesn't clarify what 'metric' values mean or how 'category' or 'path_type' are used. This is a critical gap.
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 clearly states the tool returns 'top replacement paths across the catalog' sorted by savings, payback months, or popularity. This is a specific verb (get/leaderboard) and resource (replacement paths). It does not explicitly differentiate from sibling tools like find_alternatives or list_categories, but the leaderboard concept is distinct enough to understand its purpose.
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 description implies this is used when you need a ranked list of replacement paths, but it does not explicitly state when to prefer this over alternatives or mention any exclusions beyond the data filtering. The sibling context suggests other tools for different purposes, but the description itself does not guide the agent on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList categoriesBRead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds what the result includes (counts and savings), but the lengthy privacy disclosure is unrelated to this tool's runtime behavior and adds no transparency about side effects, rate limits, or authorization. This is adequate given annotations, but not more.
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 first sentence is concise and informative, but the second sentence is a lengthy, generic privacy notice about Stackcut's data practices. It is not tool-specific, does not help an agent select or invoke this tool, and should be removed from the description. The structure is front-loaded but the second sentence wastes words.
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, idempotent list tool with no output schema, the description adequately explains the return content (categories with counts and savings). It does not mention sorting or pagination, but those are minor for a catalog listing. The privacy notice is irrelevant noise rather than a completeness gap.
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 has zero parameters and the schema is fully covered (100%). Per the baseline for zero-parameter tools, a 4 is appropriate; the description needs to explain nothing about parameters. The first sentence indirectly explains why no parameters are needed (it lists all categories globally).
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 clearly states the resource (catalog's categories) and the specific output (recipe counts and best modeled first-year saving). The purpose is unambiguous, but it does not explicitly contrast with sibling tools like search_recipes or leaderboard, so it earns a 4 rather than 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to call this tool versus alternatives. The privacy notice does not address tool selection or invocation context. An agent is left to infer that listing categories is useful for browsing, but no explicit when-to-use or exclusions are stated.
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 jobsDRead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
D1.8/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds an irrelevant privacy policy about data storage, which does not clarify the tool's behavior. It does not contradict annotations but adds no value.
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 description is verbose, includes unrelated information about choose_stack capabilities and a privacy note, and is not front-loaded with the tool's purpose. It lacks conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 provides no indication of what the tool returns. It is completely inadequate for an agent to understand or invoke this tool 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?
The tool has 0 parameters and schema coverage is 100% (empty schema). Baseline for 0 params is 4, and no parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description talks about what 'choose_stack' jobs can do, not about the tool 'list_stack_jobs' itself. It never states what this tool does, making the purpose unclear and misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. The description is entirely about a different tool and a privacy note, offering no usage context.
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 briefARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| 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/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive annotations, the description discloses rich behavioral traits: it runs on keyword rules with no model call, requires user confirmation before quoting when total.hypothetical is true, explains that ruled-out/deferred/existing jobs are never priced, and details Stackcut's data-retention policy (one-way key hashes, no billing/validation sources, no IP addresses). This is exactly the kind of operational context annotations cannot 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?
Longer than typical, but every clause earns its place: trigger, process pipeline, exclusion rule, no-model-call behavior, confirmation rule, and privacy policy. The content is front-loaded with the use case and becomes progressively more operational. Slightly dense, but there is no filler or repetition of schema text.
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 high-complexity tool (8 params, nested objects, huge unit enum, 16 siblings, no output schema), the description covers the trigger, the internal pipeline, the safety-relevant confirmation flow, the privacy boundary, and the return artifacts. It does not describe what SPEC.md/AGENTS.md/manifest contain or how scales interact, but that gap is acceptable given the schema documents the parameters and the description covers the behavioral essentials.
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 75%, so the baseline is 3; the description adds value by explaining the pricing-exclusion semantics ('what it rules out, plans for later or already has is never priced'), which clarifies how overrides/exclude_jobs relate to derived jobs, and it reinforces the spec parameter's call to avoid personal data and secrets. However, prefer and limit_per_job remain undocumented in both schema and description, and the description doesn't map parameters to the workflow steps.
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 opens with a precise trigger ('Use when the user shares a product brief or spec and asks what to build it with or what it will cost') and names the verb+resource (plan a stack from a product brief). It differentiates from siblings by naming choose_stack as the internal pricing engine it calls and by listing concrete deliverables (SPEC.md, AGENTS.md, manifest), so an agent can distinguish it from choose_stack and get_build_packet 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear, explicit entry condition: the user shares a brief/spec and asks what to build with or what it will cost. It does not, however, state exclusions or name the alternative for when the brief is already priced (e.g., go straight to choose_stack or audit_stack), so it stops short of full when-not guidance.
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
Only after the user confirms what happened: record that a cancellation went through, that they kept the service for less, that they got stuck, or that the steps had changed (and at which step). Adds one to anonymous public counters that keep the cancel library current; stores no personal data and no free text. 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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| step | No | For blocked or steps_changed: the step number where it stopped matching | |
| outcome | Yes | ||
| service | Yes | The service, as passed to get_exit_plan | |
| billed_by | Yes |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=false, the description goes well beyond annotations: it discloses that the call adds to anonymous public counters, stores no personal data and no free text, and details what Stackcut retains (vendor names, prices, hashed account keys) versus what it never stores (IPs, billing/validation sources). This is exactly the data-handling context an agent needs before writing.
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 precondition is front-loaded and each sentence carries content. The final privacy sentence is a dense run-on with a long parenthetical list, which is slightly heavy but not wasted given its compliance value.
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?
No output schema exists, so the description need not explain returns, and it explains the counter side effect instead. It is complete on privacy and preconditions, with billed_by semantics the only notable gap for a 4-parameter mutation tool.
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 50%. The description clarifies the 'step' parameter ('at which step') and restates the outcome categories, which helps. But the billed_by enum and its values are documented in neither the schema nor the description, so the description only partially compensates 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?
States a specific verb and resource ('record that a cancellation went through...') and enumerates the exact outcome categories, mapping cleanly to the outcome enum. An agent can immediately tell this writes a cancellation outcome record.
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: 'Only after the user confirms what happened.' That is real when-to-use guidance. However, it never distinguishes itself from the sibling report_outcome, which an agent could easily confuse with this tool, and names no alternatives.
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 didAInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | ||
| path_id | Yes | ||
| recipe_id | Yes |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false, so the description carries the full burden of behavioral disclosure. It goes beyond that by stating the tool increments anonymous public counters and stores no personal data, and it provides a detailed privacy disclosure about what Stackcut does and does not store. This is highly transparent and adds significant value beyond 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 core purpose is front-loaded in the first sentence, which is efficient. The second sentence is a lengthy but necessary privacy disclosure that adds bulk; while it is important, it could arguably be condensed. Overall, the structure is clear and the length is justified by the sensitivity of data handling.
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?
The description covers the purpose, precondition, side effect, and data-handling behavior. It does not describe the return value, but there is no output schema to clarify that. The main missing piece is the semantics of recipe_id, which is a required parameter and not explained. For a simple three-parameter tool, this is a moderate gap.
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 explain the parameters. It explains the outcome enum by listing the three values, and implies path_id is the replacement path. However, recipe_id is never mentioned or defined, leaving a required parameter without any semantic guidance. This is a notable gap given the low schema coverage.
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 clearly states the verb 'record' and the resource 'replacement path outcome', specifying the three possible actions (picked, switched, reverted). It also includes a precondition ('Only after the user confirms what they did') and describes the side effect (incrementing anonymous counters). This unambiguously distinguishes it from the sibling tools, which are about auditing, searching, or building stacks.
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 description gives an explicit precondition: use only after the user confirms their action. It also advises against sending personal data or secrets, which is a clear usage constraint. It does not mention alternative tools, but there is no obvious sibling that performs this same reporting function, so the guidance is sufficient for typical use.
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 libraryARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | A name or domain, e.g. 'peacock', 'vpn' | |
| category | No |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds a detailed data-handling disclosure (what is stored, what is hashed, what is never collected), which is useful context beyond the annotations, but it says nothing about pagination 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded, but the first sentence is a heavily parenthesized run-on whose vertical list largely duplicates the category enum, and the closing privacy block is long. The essential routing information (get_exit_plan) is buried in the middle rather than surfaced early.
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, yet the description only gestures at returns with 'the page and JSON for each' and never explains pagination or how limit interacts with results. For a zero-required-parameter browse tool, the purpose and privacy aspects are covered but the calling contract is thin.
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 33%: 'query' is documented in the schema, 'limit' is not described anywhere, and 'category' relies on a self-explanatory enum. The description maps loosely to query/category ('by name, domain or category') but never explains limit or default behavior, so it only partially compensates for the 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?
States a specific verb (lists) and resource (services in Stackcut's cancel library), enumerates the searchable axes (name, domain, category), and explicitly separates itself from the sibling get_exit_plan. An agent can distinguish it from get_exit_plan 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit alternative and the condition that selects it: 'Use get_exit_plan for one service's steps.' That is real routing guidance. It does not mention other plausible siblings such as list_categories or find_alternatives, so it falls short of a full when/when-not map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_recipesSearch replacement recipesARead-onlyIdempotentInspect
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. 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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | relevance | |
| limit | No | ||
| query | No | Free text, e.g. 'client approval portal' or 'semrush backlinks' | |
| 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 |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds a valuable disclosure that Stackcut stores call arguments for recommendations, specifies what is and isn't stored, and warns not to send personal data or secrets. This goes beyond the annotations, though it stops short of covering details like rate limits or auth.
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 use case and examples, and every sentence contributes either routing, parameter, output, or privacy information. The privacy list is detailed but earned; it could be tightened, but it is not padding.
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 no output schema, it describes the output as compact recipe cards with a best-priced path and points to get_recipe for full path/cost/source details. It covers the main input dimensions and the important privacy caveat. A minor gap is that it does not explicitly distinguish search_recipes from the closely named search_workflow_recipes, but the description is otherwise sufficient for correct invocation.
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 description adds human-readable meaning to the filter parameters: vendor is 'the product they pay for', feature is the relied-on capability, and path_type is expanded into 'switch, cheaper plan, open source, pay per use, agent skill, build it'. With schema coverage at 71%, this meaningfully complements the schema, though sort and limit are left to 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?
The description opens with a specific trigger ('wants a cheaper way to do a job') and names the resource: replacement recipes. It lists concrete filter dimensions and return type, and points out get_recipe and find_alternatives as different tools, so a selecting agent can tell it apart 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?
It explicitly says when to use this tool: when the user names a feature or kind of tool rather than one product, with example queries. It also gives routing guidance to find_alternatives for a single paid product and to get_recipe for exhaustive paths, which is a clear when-not-to-use statement.
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 recipesARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds meaningful behavioral disclosures: runbooks are 'guidance, not proof that a migration ran' and a detailed privacy statement about which data Stackcut stores, hashes, or never retains. This goes well beyond the structured 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?
Four sentences, each serving a distinct purpose: usage scope, return behavior, output caveat, and privacy disclosure. The privacy sentence is dense but valuable; the description is front-loaded with the core usage guidance and stays appropriately sized.
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 tool with three optional parameters and no output schema, the definition covers the essential context: when to use it, what it returns, a caveat about output interpretation, and data-retention behavior. It lacks a mention of pagination or exact response structure, but those are less critical given the sibling get_workflow_recipe provides full details.
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 have descriptions; limit does not). The description adds example queries that match the query parameter but does not clarify limit semantics or add parameter-specific details beyond what the schema already provides. It meets the baseline for medium coverage but does not exceed it.
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 ('search') on a specific resource ('workflow recipes') and scopes it to 'whole operational change' rather than a single subscription, with concrete examples. It also distinguishes itself from the sibling get_workflow_recipe by noting that tool returns one recipe in full.
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?
Explicitly says to use for a whole operational change rather than a single subscription, giving clear when-to-use context. It also points to get_workflow_recipe for retrieving a full recipe, but does not explicitly name search_recipes as the single-subscription alternative, so the routing is clear but not exhaustive.
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)ARead-onlyIdempotentInspect
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): don't send personal data or secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly, idempotent, and non-destructive annotations, the description discloses the iterative protocol, the fact that Stackcut stores call arguments for recommendations, and detailed data-handling behavior: what is stored (hashed account keys, no billing sources, no IPs) and what must never be sent. This adds substantial behavioral context the annotations do not cover.
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 trigger condition and input options, then flows into the iterative loop and privacy caveats. The final privacy sentence is long but carries necessary behavioral disclosure. Overall it is dense and efficient with little wasted wording.
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 still sketches the return shape ('the few missing facts that would change the answer, ranked by what's at stake, each with where to find it') and the termination condition (status is 'enough'). It covers input choices, constraints, and storage behavior, making it sufficient for an agent to invoke the tool 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 100%, so the baseline is 3. The description adds useful semantics by clarifying that the manifest is an alternative to the vendors+team_size pair, and by constraining acceptable values ('Send counts, prices, feature and job names only'). This goes beyond the schema's individual descriptions.
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 clearly states the tool starts a baseline stack audit, surfacing missing facts that would change the decision. Phrases like 'Start here' and 'call again until status is enough' signal its entry-point role and distinguish it from later steps. However, it does not explicitly name sibling tools such as audit_stack, so differentiation relies on 'baseline' and 'start here' rather than direct comparison.
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?
Provides explicit when-to-use triggers: '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.' It also specifies input options ('vendors and team_size (or a stack manifest)'), the iterative loop, and the handoff to next.tool with next.arguments. This is comprehensive guidance for selecting and driving the tool.
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.
3 tool updates
- Added
get_exit_plan - Added
report_exit_outcome - Added
search_exits
10 tool updates
- Changed
audit_stack82 fields changed- added
Input schema / properties / services / items / properties / billingAdded 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" +} - added
Input schema / properties / services / items / properties / files_referencing / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / replacement_validationAdded 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" +} - added
Input schema / properties / services / items / properties / service_idAdded 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" +} - added
Input schema / properties / services / items / properties / usage / properties / MAU / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / active_accounts / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / apps / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / audio_minutes_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / bandwidth_gb / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / browser_hours_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / cache_commands_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / cached_tokens_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / call_participants / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / characters_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / concurrent_sessions / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / contacts / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / cpu_ms_per_request / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / credits_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / credits_usd_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / db_gb / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / disputes_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / domains / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / emails_per_day / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / emails_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / errors_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / event_types / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / events_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / files / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / gmv_usd_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / gpu_seconds_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / history_days / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / images_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / inbound_emails_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / inboxes / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / job_executions_per_day / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / job_executions_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / keywords_tracked / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / mau / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / meeting_minutes / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / members / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / monitors / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / mtu / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / object_reads_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / object_writes_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / pageviews_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / payout_volume_usd_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / payouts_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / phone_minutes_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / projects / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / proxy_gb_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / records / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / requests_per_day / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / requests_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / responses_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / revenue_usd_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / sandbox_hours_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / scim_connections / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / searches_per_hour / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / searches_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / seats / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / session_minutes / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / sites / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / sms_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / sso_connections / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / sso_users / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / storage_gb / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / stream_hours_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / tasks_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / tokens_in_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / tokens_out_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / tokens_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / transactions_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / vcpu_hours_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / vector_queries_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / vector_read_units_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / vector_write_units_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / vectors_stored / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / verifications_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / video_minutes / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / video_minutes_delivered_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / video_minutes_stored / maximumAdded value: +1000000000000 - added
Input schema / properties / services / items / properties / usage / properties / videos / maximumAdded value: +1000000000000
- Changed
choose_stack8 fields changed- added
Input schema / properties / budget_monthly_usd / maximumAdded value: +1000000000000 - added
Input schema / properties / needs / items / properties / peak_volumeAdded 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" +} - added
Input schema / properties / needs / items / properties / per_user / items / properties / unit / maxLengthAdded value: +2000 - added
Input schema / properties / needs / items / properties / volume / properties / unit / maxLengthAdded value: +2000 - added
Input schema / properties / needs / items / properties / volumes / items / properties / unit / maxLengthAdded value: +2000 - added
Input schema / properties / prefer / maxLengthAdded value: +2000 - added
Input schema / properties / scale_by / maxLengthAdded value: +2000 - added
Input schema / properties / unit_economics / properties / billing / maxLengthAdded value: +2000
- Changed
find_alternatives80 fields changed- added
Input schema / properties / billingAdded 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" +} - added
Input schema / properties / replacement_validationAdded 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" +} - added
Input schema / properties / usage / properties / MAU / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / active_accounts / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / apps / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / audio_minutes_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / bandwidth_gb / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / browser_hours_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / cache_commands_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / cached_tokens_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / call_participants / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / characters_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / concurrent_sessions / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / contacts / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / cpu_ms_per_request / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / credits_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / credits_usd_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / db_gb / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / disputes_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / domains / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / emails_per_day / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / emails_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / errors_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / event_types / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / events_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / files / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / gmv_usd_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / gpu_seconds_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / history_days / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / images_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / inbound_emails_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / inboxes / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / job_executions_per_day / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / job_executions_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / keywords_tracked / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / mau / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / meeting_minutes / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / members / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / monitors / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / mtu / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / object_reads_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / object_writes_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / pageviews_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / payout_volume_usd_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / payouts_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / phone_minutes_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / projects / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / proxy_gb_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / records / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / requests_per_day / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / requests_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / responses_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / revenue_usd_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / sandbox_hours_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / scim_connections / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / searches_per_hour / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / searches_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / seats / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / session_minutes / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / sites / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / sms_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / sso_connections / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / sso_users / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / storage_gb / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / stream_hours_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / tasks_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / tokens_in_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / tokens_out_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / tokens_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / transactions_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / vcpu_hours_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / vector_queries_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / vector_read_units_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / vector_write_units_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / vectors_stored / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / verifications_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / video_minutes / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / video_minutes_delivered_per_month / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / video_minutes_stored / maximumAdded value: +1000000000000 - added
Input schema / properties / usage / properties / videos / maximumAdded value: +1000000000000
- Added
get_workflow_recipe - Changed
leaderboard2 fields changed- added
Input schema / properties / metric / maxLengthAdded value: +2000 - added
Input schema / properties / path_type / maxLengthAdded value: +2000
- Changed
plan_stack_from_spec4 fields changed- added
Input schema / properties / overrides / items / properties / basis / maxLengthAdded value: +2000 - added
Input schema / properties / overrides / items / properties / unit / maxLengthAdded value: +2000 - added
Input schema / properties / prefer / maxLengthAdded value: +2000 - added
Input schema / properties / unit_economics / properties / billing / maxLengthAdded value: +2000
- Changed
report_outcome1 field changed- added
Input schema / properties / outcome / maxLengthAdded value: +2000
- Changed
search_recipes2 fields changed- added
Input schema / properties / path_type / maxLengthAdded value: +2000 - added
Input schema / properties / sort / maxLengthAdded value: +2000
- Added
search_workflow_recipes - Added
start_audit
4 tool updates
- Changed
audit_stack23 fields changed- added
Input schema / properties / active_usersAdded value: +{ + "description": "People or accounts active in the last 30 days (0 = unused: cleanup levers and sanity checks)", + "maximum": 1000000000, + "minimum": 0, + "type": "number" +} - added
Input schema / properties / revenue_usd_per_monthAdded 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" +} - added
Input schema / properties / services / items / properties / accountAdded 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" +} - added
Input schema / properties / services / items / properties / active_usersAdded value: +{ + "description": "People or accounts active in the last 30 days (0 = unused: cleanup levers and sanity checks)", + "maximum": 1000000000, + "minimum": 0, + "type": "number" +} - changed
Input schema / properties / services / items / properties / confidence / descriptionPrevious value: -"detect.mjs output (ignored)"New value: +"detect.mjs output: 'low' (only a config file) means no paid plan is assumed" - added
Input schema / properties / services / items / properties / confirmedAdded 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" +} - changed
Input schema / properties / services / items / properties / files_referencing / descriptionPrevious value: -"detect.mjs output (ignored)"New value: +"detect.mjs output: marks the line as scan-only (unconfirmed); never read as usage" - added
Input schema / properties / services / items / properties / last_activeAdded 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" +} - added
Input schema / properties / services / items / properties / revenue_usd_per_monthAdded 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" +} - added
Input schema / properties / services / items / properties / shared_withAdded 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" +} - changed
Input schema / properties / services / items / properties / usage / descriptionPrevious 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." - added
Input schema / properties / services / items / properties / usage / properties / cache_commands_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / gpu_seconds_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / mtuAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / phone_minutes_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / revenue_usd_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / searches_per_hourAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / sms_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / vector_queries_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / vector_read_units_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / vector_write_units_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / services / items / properties / usage / properties / vectors_storedAdded value: +{ + "minimum": 0, + "type": "number" +} - changed
Input schema / properties / services / maxItemsPrevious value: -60New value: +200
- Changed
choose_stack3 fields changed- changed
Input schema / properties / needs / items / properties / per_user / items / properties / unit / enumPrevious 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" +] - changed
Input schema / properties / needs / items / properties / volume / properties / unit / enumPrevious 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" +] - changed
Input schema / properties / needs / items / properties / volumes / items / properties / unit / enumPrevious 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" +]
- Changed
find_alternatives18 fields changed- added
Input schema / properties / active_usersAdded value: +{ + "description": "People or accounts active in the last 30 days (0 = unused: cleanup levers and sanity checks)", + "maximum": 1000000000, + "minimum": 0, + "type": "number" +} - added
Input schema / properties / confirmedAdded 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" +} - changed
Input schema / properties / evidence / descriptionPrevious 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'" - added
Input schema / properties / last_activeAdded 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" +} - added
Input schema / properties / revenue_usd_per_monthAdded 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" +} - added
Input schema / properties / shared_withAdded 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" +} - changed
Input schema / properties / usage / descriptionPrevious 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." - added
Input schema / properties / usage / properties / cache_commands_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / gpu_seconds_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / mtuAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / phone_minutes_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / revenue_usd_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / searches_per_hourAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / sms_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / vector_queries_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / vector_read_units_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / vector_write_units_per_monthAdded value: +{ + "minimum": 0, + "type": "number" +} - added
Input schema / properties / usage / properties / vectors_storedAdded value: +{ + "minimum": 0, + "type": "number" +}
- Changed
plan_stack_from_spec1 field changed- changed
Input schema / properties / overrides / items / properties / unit / enumPrevious 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" +]
12 tool updates
- Changed
audit_stack23 fields changed- changed
Input schema / properties / services / items / additionalPropertiesPrevious value: -trueNew value: +false - added
Input schema / properties / services / items / properties / categoryAdded value: +{ + "description": "detect.mjs output (ignored)", + "maxLength": 100, + "type": "string" +} - added
Input schema / properties / services / items / properties / confidenceAdded value: +{ + "description": "detect.mjs output (ignored)", + "maxLength": 20, + "type": "string" +} - added
Input schema / properties / services / items / properties / evidence / descriptionAdded value: +"Scan evidence labels and usage facts in words ('db 1.5 GB', '40,000 emails/mo', '37 domains')" - added
Input schema / properties / services / items / properties / evidence / items / maxLengthAdded value: +500 - added
Input schema / properties / services / items / properties / evidence / maxItemsAdded value: +50 - added
Input schema / properties / services / items / properties / feature_countsAdded value: +{ + "description": "detect.mjs output (ignored)", + "items": { + "type": "object" + }, + "maxItems": 100, + "type": "array" +} - changed
Input schema / properties / services / items / properties / features_used / descriptionPrevious value: -"Features the code or the user relies on"New value: +"Features the code or the user relies on; sizes and counts ('4,000 contacts') are read as usage" - added
Input schema / properties / services / items / properties / features_used / items / maxLengthAdded value: +200 - added
Input schema / properties / services / items / properties / features_used / maxItemsAdded value: +50 - added
Input schema / properties / services / items / properties / files_referencingAdded value: +{ + "description": "detect.mjs output (ignored)", + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / services / items / properties / in_catalogAdded value: +{ + "description": "detect.mjs output (ignored)", + "type": "boolean" +} - changed
Input schema / properties / services / items / properties / monthly_spend_usd / descriptionPrevious value: -"What they pay per month for it, if known"New value: +"What they pay per month for it, all seats, if known" - added
Input schema / properties / services / items / properties / monthly_spend_usd / maximumAdded value: +1000000 - added
Input schema / properties / services / items / properties / nameAdded value: +{ + "description": "detect.mjs output (ignored)", + "maxLength": 200, + "type": "string" +} - added
Input schema / properties / services / items / properties / planAdded value: +{ + "description": "Their plan, e.g. 'Business Standard' (else read from the name or evidence)", + "maxLength": 100, + "type": "string" +} - added
Input schema / properties / services / items / properties / projectAdded value: +{ + "description": "Which of their projects or products this line is for (portfolio audits): lines of one vendor across projects are audited as one account. Give each project's own usage on its line and the account's bill once", + "maxLength": 100, + "minLength": 1, + "type": "string" +} - added
Input schema / properties / services / items / properties / seats / descriptionAdded value: +"Paid seats" - added
Input schema / properties / services / items / properties / seats / maximumAdded value: +100000 - added
Input schema / properties / services / items / properties / usageAdded value: +{ + "additionalProperties": false, + "description": "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.", + "properties": { + "MAU": { + "minimum": 0, + "type": "number" + }, + "active_accounts": { + "minimum": 0, + "type": "number" + }, + "apps": { + "minimum": 0, + "type": "number" + }, + "audio_minutes_per_month": { + "minimum": 0, + "type": "number" + }, + "bandwidth_gb": { + "minimum": 0, + "type": "number" + }, + "browser_hours_per_month": { + "minimum": 0, + "type": "number" + }, + "cached_tokens_per_month": { + "minimum": 0, + "type": "number" + }, + "call_participants": { + "minimum": 0, + "type": "number" + }, + "characters_per_month": { + "minimum": 0, + "type": "number" + }, + "concurrent_sessions": { + "minimum": 0, + "type": "number" + }, + "contacts": { + "minimum": 0, + "type": "number" + }, + "cpu_ms_per_request": { + "minimum": 0, + "type": "number" + }, + "credits_per_month": { + "minimum": 0, + "type": "number" + }, + "credits_usd_per_month": { + "minimum": 0, + "type": "number" + }, + "db_gb": { + "minimum": 0, + "type": "number" + }, + "disputes_per_month": { + "minimum": 0, + "type": "number" + }, + "domains": { + "minimum": 0, + "type": "number" + }, + "emails_per_day": { + "minimum": 0, + "type": "number" + }, + "emails_per_month": { + "minimum": 0, + "type": "number" + }, + "errors_per_month": { + "minimum": 0, + "type": "number" + }, + "event_types": { + "minimum": 0, + "type": "number" + }, + "events_per_month": { + "minimum": 0, + "type": "number" + }, + "files": { + "minimum": 0, + "type": "number" + }, + "gmv_usd_per_month": { + "minimum": 0, + "type": "number" + }, + "history_days": { + "minimum": 0, + "type": "number" + }, + "images_per_month": { + "minimum": 0, + "type": "number" + }, + "inbound_emails_per_month": { + "minimum": 0, + "type": "number" + }, + "inboxes": { + "minimum": 0, + "type": "number" + }, + "job_executions_per_day": { + "minimum": 0, + "type": "number" + }, + "job_executions_per_month": { + "minimum": 0, + "type": "number" + }, + "keywords_tracked": { + "minimum": 0, + "type": "number" + }, + "mau": { + "minimum": 0, + "type": "number" + }, + "meeting_minutes": { + "minimum": 0, + "type": "number" + }, + "members": { + "minimum": 0, + "type": "number" + }, + "monitors": { + "minimum": 0, + "type": "number" + }, + "object_reads_per_month": { + "minimum": 0, + "type": "number" + }, + "object_writes_per_month": { + "minimum": 0, + "type": "number" + }, + "pageviews_per_month": { + "minimum": 0, + "type": "number" + }, + "payout_volume_usd_per_month": { + "minimum": 0, + "type": "number" + }, + "payouts_per_month": { + "minimum": 0, + "type": "number" + }, + "projects": { + "minimum": 0, + "type": "number" + }, + "proxy_gb_per_month": { + "minimum": 0, + "type": "number" + }, + "records": { + "minimum": 0, + "type": "number" + }, + "requests_per_day": { + "minimum": 0, + "type": "number" + }, + "requests_per_month": { + "minimum": 0, + "type": "number" + }, + "responses_per_month": { + "minimum": 0, + "type": "number" + }, + "sandbox_hours_per_month": { + "minimum": 0, + "type": "number" + }, + "scim_connections": { + "minimum": 0, + "type": "number" + }, + "searches_per_month": { + "minimum": 0, + "type": "number" + }, + "seats": { + "minimum": 0, + "type": "number" + }, + "session_minutes": { + "minimum": 0, + "type": "number" + }, + "sites": { + "minimum": 0, + "type": "number" + }, + "sso_connections": { + "minimum": 0, + "type": "number" + }, + "sso_users": { + "minimum": 0, + "type": "number" + }, + "storage_gb": { + "minimum": 0, + "type": "number" + }, + "stream_hours_per_month": { + "minimum": 0, + "type": "number" + }, + "tasks_per_month": { + "minimum": 0, + "type": "number" + }, + "tokens_in_per_month": { + "minimum": 0, + "type": "number" + }, + "tokens_out_per_month": { + "minimum": 0, + "type": "number" + }, + "tokens_per_month": { + "minimum": 0, + "type": "number" + }, + "transactions_per_month": { + "minimum": 0, + "type": "number" + }, + "vcpu_hours_per_month": { + "minimum": 0, + "type": "number" + }, + "verifications_per_month": { + "minimum": 0, + "type": "number" + }, + "video_minutes": { + "minimum": 0, + "type": "number" + }, + "video_minutes_delivered_per_month": { + "minimum": 0, + "type": "number" + }, + "video_minutes_stored": { + "minimum": 0, + "type": "number" + }, + "videos": { + "minimum": 0, + "type": "number" + } + }, + "type": "object" +} - changed
Input schema / properties / services / items / properties / vendor / descriptionPrevious value: -"Vendor id from the scan (e.g. 'sendgrid') or a product name ('Airtable')"New value: +"Vendor id from the scan (e.g. 'sendgrid') or a product name as on the invoice ('Airtable', 'Slack Pro')" - added
Input schema / properties / services / items / properties / vendor / maxLengthAdded value: +200 - added
Input schema / properties / services / items / properties / vendor / minLengthAdded value: +1
- Changed
choose_stack20 fields changed- added
Input schema / properties / needs / items / properties / avg_amount_usdAdded value: +{ + "description": "Average payment in USD; with transactions it prices payment fees", + "maximum": 10000000, + "minimum": 0, + "type": "number" +} - changed
Input schema / properties / needs / items / properties / features / descriptionPrevious value: -"Must-have features, e.g. ['Postgres database', 'Auth']"New value: +"Must-haves, e.g. ['Custom domain', 'CAPTCHA solving', 'platform holds funds', 'refunds enabled', 'unbounded sessions', '2 vCPU / 4 GiB', 'gpt-6-sol']. Sizes and counts ('30 GB database') are checked as volumes; a model or plan name pins that model; SSO, SOC 2, audit logs and region needs are listed as unverified requirements" - added
Input schema / properties / needs / items / properties / features / items / maxLengthAdded value: +200 - added
Input schema / properties / needs / items / properties / features / items / minLengthAdded value: +1 - added
Input schema / properties / needs / items / properties / features / maxItemsAdded value: +20 - changed
Input schema / properties / needs / items / properties / job / descriptionPrevious value: -"A category id from list_stack_jobs (e.g. database, auth, hosting, email_transactional) or plain words ('send email', 'postgres')"New value: +"A job id from list_stack_jobs (llm_inference, image_generation_api, video_delivery, object_storage, sandbox_compute, browser_automation, job_queue, auth_b2b, email_inbound, identity_verification, marketplace_payouts, database, auth, hosting, email_transactional, …) or plain words ('send email', 'video hosting (HLS)', 'KYC'). Unknown or ambiguous jobs come back in unsupported_jobs, never as an error" - added
Input schema / properties / needs / items / properties / job / maxLengthAdded value: +200 - added
Input schema / properties / needs / items / properties / job / minLengthAdded value: +1 - added
Input schema / properties / needs / items / properties / per_userAdded value: +{ + "description": "Volumes per monthly active user per month, e.g. [{amount: 6, unit: 'images'}]; multiplied by MAU (from scales, a mau volume or the project text)", + "items": { + "additionalProperties": false, + "properties": { + "amount": { + "maximum": 1000000000000000, + "minimum": 0, + "type": "number" + }, + "unit": { + "description": "A units.json unit, or an alias: tokens_in, tokens_out, images, gb_stored, gb_egress, transactions, gmv_usd, sandbox_seconds, sandbox_hours, vcpu_hours, browser_hours, job_executions, verifications, inbound_emails, video_minutes_delivered, sso_connections, sso_users, emails, events, requests, credits_usd, MAU (= mau). *_per_month units are monthly, *_per_day daily, *_gb and video_minutes_stored are totals.", + "enum": [ + "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" + ], + "type": "string" + } + }, + "required": [ + "amount", + "unit" + ], + "type": "object" + }, + "maxItems": 8, + "minItems": 1, + "type": "array" +} - added
Input schema / properties / needs / items / properties / sandbox_sizeAdded value: +{ + "additionalProperties": false, + "description": "Sandbox size for sandbox_compute", + "properties": { + "ram_gib": { + "maximum": 4096, + "minimum": 0.1, + "type": "number" + }, + "vcpu": { + "maximum": 512, + "minimum": 0.1, + "type": "number" + } + }, + "type": "object" +} - added
Input schema / properties / needs / items / properties / volume / properties / amount / maximumAdded value: +1000000000000000 - added
Input schema / properties / needs / items / properties / volume / properties / unit / descriptionAdded value: +"A units.json unit, or an alias: tokens_in, tokens_out, images, gb_stored, gb_egress, transactions, gmv_usd, sandbox_seconds, sandbox_hours, vcpu_hours, browser_hours, job_executions, verifications, inbound_emails, video_minutes_delivered, sso_connections, sso_users, emails, events, requests, credits_usd, MAU (= mau). *_per_month units are monthly, *_per_day daily, *_gb and video_minutes_stored are totals." - changed
Input schema / properties / needs / items / properties / volume / properties / unit / enumPrevious value: -[ - "MAU", - "emails_per_month", - "events_per_month", - "requests_per_month", - "seats" -]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", + "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" +] - added
Input schema / properties / needs / items / properties / volumesAdded value: +{ + "description": "Several dimensions at once, e.g. [{amount: 15000000, unit: 'tokens_in'}, {amount: 7500000, unit: 'tokens_out'}]", + "items": { + "additionalProperties": false, + "properties": { + "amount": { + "maximum": 1000000000000000, + "minimum": 0, + "type": "number" + }, + "unit": { + "description": "A units.json unit, or an alias: tokens_in, tokens_out, images, gb_stored, gb_egress, transactions, gmv_usd, sandbox_seconds, sandbox_hours, vcpu_hours, browser_hours, job_executions, verifications, inbound_emails, video_minutes_delivered, sso_connections, sso_users, emails, events, requests, credits_usd, MAU (= mau). *_per_month units are monthly, *_per_day daily, *_gb and video_minutes_stored are totals.", + "enum": [ + "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" + ], + "type": "string" + } + }, + "required": [ + "amount", + "unit" + ], + "type": "object" + }, + "maxItems": 8, + "minItems": 1, + "type": "array" +} - added
Input schema / properties / prefer / descriptionAdded value: +"managed leaves out self-hosted options" - changed
Input schema / properties / project / descriptionPrevious value: -"What is being built, one line"New value: +"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." - added
Input schema / properties / project / maxLengthAdded value: +4000 - added
Input schema / properties / scale_byAdded value: +{ + "default": "mau", + "description": "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", + "enum": [ + "mau", + "multiplier" + ], + "type": "string" +} - added
Input schema / properties / scalesAdded value: +{ + "description": "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", + "items": { + "maximum": 1000000000, + "minimum": 0.001, + "type": "number" + }, + "maxItems": 6, + "minItems": 1, + "type": "array" +} - added
Input schema / properties / unit_economicsAdded value: +{ + "additionalProperties": false, + "description": "Revenue model for gross margin per scale: price_usd with conversion_rate, or revenue_per_mau", + "properties": { + "billing": { + "default": "monthly", + "description": "one_time: price_usd per purchase, conversion_rate = purchases per MAU per month", + "enum": [ + "monthly", + "one_time" + ], + "type": "string" + }, + "conversion_rate": { + "description": "Share of MAU who pay, e.g. 0.03", + "maximum": 1, + "minimum": 0, + "type": "number" + }, + "price_usd": { + "description": "What a paying user pays", + "maximum": 1000000, + "minimum": 0, + "type": "number" + }, + "revenue_per_mau": { + "description": "Average monthly revenue per MAU (instead of price_usd × conversion_rate)", + "maximum": 10000, + "minimum": 0, + "type": "number" + }, + "variable_cost_alert_pct": { + "default": 20, + "description": "Flag jobs whose monthly cost is above this % of revenue", + "maximum": 100, + "minimum": 1, + "type": "number" + } + }, + "type": "object" +}
- Changed
find_alternatives12 fields changed- added
Input schema / properties / evidenceAdded value: +{ + "description": "Usage facts in words, read best effort: 'db 1.5 GB', '40,000 emails/mo', '37 domains', '3,000 MAU'", + "items": { + "maxLength": 500, + "type": "string" + }, + "maxItems": 50, + "type": "array" +} - changed
Input schema / properties / features_used / descriptionPrevious value: -"Features they actually use"New value: +"Features they actually use; sizes and counts ('4,000 contacts', 'videos over 5 minutes') are read as usage" - added
Input schema / properties / features_used / items / maxLengthAdded value: +200 - added
Input schema / properties / features_used / maxItemsAdded value: +50 - changed
Input schema / properties / monthly_spend_usd / descriptionPrevious value: -"What they pay per month today (replaces the modeled baseline)"New value: +"What they pay per month today, all seats (replaces the modeled baseline)" - added
Input schema / properties / monthly_spend_usd / maximumAdded value: +1000000 - added
Input schema / properties / planAdded value: +{ + "description": "Their plan, e.g. 'Essential' (else read from the vendor name)", + "maxLength": 100, + "type": "string" +} - added
Input schema / properties / seatsAdded value: +{ + "description": "Paid seats; per-seat prices on both sides scale with it", + "maximum": 100000, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / usageAdded value: +{ + "additionalProperties": false, + "description": "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.", + "properties": { + "MAU": { + "minimum": 0, + "type": "number" + }, + "active_accounts": { + "minimum": 0, + "type": "number" + }, + "apps": { + "minimum": 0, + "type": "number" + }, + "audio_minutes_per_month": { + "minimum": 0, + "type": "number" + }, + "bandwidth_gb": { + "minimum": 0, + "type": "number" + }, + "browser_hours_per_month": { + "minimum": 0, + "type": "number" + }, + "cached_tokens_per_month": { + "minimum": 0, + "type": "number" + }, + "call_participants": { + "minimum": 0, + "type": "number" + }, + "characters_per_month": { + "minimum": 0, + "type": "number" + }, + "concurrent_sessions": { + "minimum": 0, + "type": "number" + }, + "contacts": { + "minimum": 0, + "type": "number" + }, + "cpu_ms_per_request": { + "minimum": 0, + "type": "number" + }, + "credits_per_month": { + "minimum": 0, + "type": "number" + }, + "credits_usd_per_month": { + "minimum": 0, + "type": "number" + }, + "db_gb": { + "minimum": 0, + "type": "number" + }, + "disputes_per_month": { + "minimum": 0, + "type": "number" + }, + "domains": { + "minimum": 0, + "type": "number" + }, + "emails_per_day": { + "minimum": 0, + "type": "number" + }, + "emails_per_month": { + "minimum": 0, + "type": "number" + }, + "errors_per_month": { + "minimum": 0, + "type": "number" + }, + "event_types": { + "minimum": 0, + "type": "number" + }, + "events_per_month": { + "minimum": 0, + "type": "number" + }, + "files": { + "minimum": 0, + "type": "number" + }, + "gmv_usd_per_month": { + "minimum": 0, + "type": "number" + }, + "history_days": { + "minimum": 0, + "type": "number" + }, + "images_per_month": { + "minimum": 0, + "type": "number" + }, + "inbound_emails_per_month": { + "minimum": 0, + "type": "number" + }, + "inboxes": { + "minimum": 0, + "type": "number" + }, + "job_executions_per_day": { + "minimum": 0, + "type": "number" + }, + "job_executions_per_month": { + "minimum": 0, + "type": "number" + }, + "keywords_tracked": { + "minimum": 0, + "type": "number" + }, + "mau": { + "minimum": 0, + "type": "number" + }, + "meeting_minutes": { + "minimum": 0, + "type": "number" + }, + "members": { + "minimum": 0, + "type": "number" + }, + "monitors": { + "minimum": 0, + "type": "number" + }, + "object_reads_per_month": { + "minimum": 0, + "type": "number" + }, + "object_writes_per_month": { + "minimum": 0, + "type": "number" + }, + "pageviews_per_month": { + "minimum": 0, + "type": "number" + }, + "payout_volume_usd_per_month": { + "minimum": 0, + "type": "number" + }, + "payouts_per_month": { + "minimum": 0, + "type": "number" + }, + "projects": { + "minimum": 0, + "type": "number" + }, + "proxy_gb_per_month": { + "minimum": 0, + "type": "number" + }, + "records": { + "minimum": 0, + "type": "number" + }, + "requests_per_day": { + "minimum": 0, + "type": "number" + }, + "requests_per_month": { + "minimum": 0, + "type": "number" + }, + "responses_per_month": { + "minimum": 0, + "type": "number" + }, + "sandbox_hours_per_month": { + "minimum": 0, + "type": "number" + }, + "scim_connections": { + "minimum": 0, + "type": "number" + }, + "searches_per_month": { + "minimum": 0, + "type": "number" + }, + "seats": { + "minimum": 0, + "type": "number" + }, + "session_minutes": { + "minimum": 0, + "type": "number" + }, + "sites": { + "minimum": 0, + "type": "number" + }, + "sso_connections": { + "minimum": 0, + "type": "number" + }, + "sso_users": { + "minimum": 0, + "type": "number" + }, + "storage_gb": { + "minimum": 0, + "type": "number" + }, + "stream_hours_per_month": { + "minimum": 0, + "type": "number" + }, + "tasks_per_month": { + "minimum": 0, + "type": "number" + }, + "tokens_in_per_month": { + "minimum": 0, + "type": "number" + }, + "tokens_out_per_month": { + "minimum": 0, + "type": "number" + }, + "tokens_per_month": { + "minimum": 0, + "type": "number" + }, + "transactions_per_month": { + "minimum": 0, + "type": "number" + }, + "vcpu_hours_per_month": { + "minimum": 0, + "type": "number" + }, + "verifications_per_month": { + "minimum": 0, + "type": "number" + }, + "video_minutes": { + "minimum": 0, + "type": "number" + }, + "video_minutes_delivered_per_month": { + "minimum": 0, + "type": "number" + }, + "video_minutes_stored": { + "minimum": 0, + "type": "number" + }, + "videos": { + "minimum": 0, + "type": "number" + } + }, + "type": "object" +} - changed
Input schema / properties / vendor / descriptionPrevious value: -"Product name, e.g. 'Typeform'"New value: +"Product name as on the invoice, e.g. 'Typeform', 'Slack Pro', 'HubSpot Sales Hub Starter'" - added
Input schema / properties / vendor / maxLengthAdded value: +200 - added
Input schema / properties / vendor / minLengthAdded value: +1
- Changed
get_build_packet2 fields changed- added
Input schema / properties / recipe_id / maxLengthAdded value: +200 - added
Input schema / properties / recipe_id / minLengthAdded value: +1
- Changed
get_detection_rules4 fields changed- changed
Input schema / properties / vendors / descriptionPrevious value: -"Only these vendor ids (default: all)"New value: +"Only these vendors, by id or name (default: all)" - added
Input schema / properties / vendors / items / maxLengthAdded value: +200 - added
Input schema / properties / vendors / items / minLengthAdded value: +1 - added
Input schema / properties / vendors / maxItemsAdded value: +200
- Changed
get_my_plan1 field changed- added
Input schema / properties / code / maxLengthAdded value: +200
- Changed
get_recipe2 fields changed- added
Input schema / properties / id / maxLengthAdded value: +200 - added
Input schema / properties / id / minLengthAdded value: +1
- Added
get_usage_questions - Changed
leaderboard2 fields changed- added
Input schema / properties / category / maxLengthAdded value: +100 - added
Input schema / properties / category / minLengthAdded value: +1
- Added
plan_stack_from_spec - Changed
report_outcome4 fields changed- added
Input schema / properties / path_id / maxLengthAdded value: +200 - added
Input schema / properties / path_id / minLengthAdded value: +1 - added
Input schema / properties / recipe_id / maxLengthAdded value: +200 - added
Input schema / properties / recipe_id / minLengthAdded value: +1
- Changed
search_recipes8 fields changed- added
Input schema / properties / category / maxLengthAdded value: +100 - added
Input schema / properties / category / minLengthAdded value: +1 - added
Input schema / properties / feature / maxLengthAdded value: +200 - added
Input schema / properties / feature / minLengthAdded value: +1 - added
Input schema / properties / query / maxLengthAdded value: +300 - changed
Input schema / properties / vendor / descriptionPrevious value: -"Product currently paid for, e.g. 'Airtable', 'Salesforce', 'Semrush'"New value: +"Product currently paid for, e.g. 'Airtable', 'Salesforce', 'Semrush Pro'" - added
Input schema / properties / vendor / maxLengthAdded value: +200 - added
Input schema / properties / vendor / minLengthAdded value: +1
2 tool updates
- Changed
leaderboard1 field changed- changed
Input schema / properties / path_type / enumPrevious value: -[ - "switch", - "downgrade", - "open_source", - "per_use", - "build", - "bundled" -]New value: +[ + "switch", + "downgrade", + "open_source", + "per_use", + "agent_skill", + "build", + "bundled" +]
- Changed
search_recipes1 field changed- changed
Input schema / properties / path_type / enumPrevious value: -[ - "switch", - "downgrade", - "open_source", - "per_use", - "build", - "bundled" -]New value: +[ + "switch", + "downgrade", + "open_source", + "per_use", + "agent_skill", + "build", + "bundled" +]
12 tool updates
- First observed
audit_stack - First observed
choose_stack - First observed
find_alternatives - First observed
get_build_packet - First observed
get_detection_rules - First observed
get_my_plan - First observed
get_recipe - First observed
leaderboard - First observed
list_categories - First observed
list_stack_jobs - First observed
report_outcome - First observed
search_recipes
Related MCP Connectors
Verified SaaS, AI, and LLM pricing for 490+ tools: plans, hidden costs, TCO, and alternatives.
Cloud cost + FinOps knowledge for AI agents: AWS/Azure/GCP optimisation, AI spend, waste playbooks.
Audit a pasted SaaS subscription list for redundant-category overlap and overspend.
B2B GTM stack intelligence: search ~400 tools, compare vendors, find overlaps, audit SaaS spend.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceA dated log of SaaS price changes across 494 tools: old price, new price and verification date for every move, plus category-level pulse and the biggest recorded increases.36 npm2MIT
- AlicenseNot gradedqualityNot gradedmaintenanceIntelligent multi-model orchestrator with dynamic routing that optimizes AI costs by prioritizing free models and escalating to paid tiers only when needed, with stateless architecture using Redis and PostgreSQL.38 npm-
- AlicenseAqualityAmaintenanceLocal-first FinOps MCP server. Ask about your AWS, Azure, GCP, and SaaS costs in plain English. Anomaly detection, rightsizing, idle-resource cleanup, and Jira/Linear ticketing. Credentials never leave your machine.1018Apache 2.0
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.