StackSwap
REMOTE · STACKSWAP.AI · SCANNED AUG 3
B2B GTM stack intelligence: search ~400 tools, compare vendors, find overlaps, audit SaaS spend.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score →
Endpoint Security66
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 32 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC is configured correctly; the domain's records validate against the full chain to the root. View diagnostics → Pass
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability61
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 7667 tokens (~239/item across 32 items; 32 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management27
- Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Capabilities60
- Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · stackswap.ai
claude mcp add --transport http stonesofcreation-stackswap https://stackswap.ai/api/mcp
[mcp_servers.stonesofcreation-stackswap] url = "https://stackswap.ai/api/mcp"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"stonesofcreation-stackswap": {
"type": "remote",
"url": "https://stackswap.ai/api/mcp",
"enabled": true
}
}
} openclaw mcp add stonesofcreation-stackswap --url https://stackswap.ai/api/mcp --transport streamable-http
mcp_servers:
stonesofcreation-stackswap:
url: "https://stackswap.ai/api/mcp" {
"mcpServers": {
"stonesofcreation-stackswap": {
"type": "http",
"url": "https://stackswap.ai/api/mcp"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 3 Aug 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.
- 1 Aug 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.
- 31 Jul 26 +2
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 −2
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 29 Jul 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.
- 28 Jul 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.
- 27 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 62
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Aug 2026 · Probed https://stackswap.ai/api/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=stackswap.ai | CN=YR1,O=Let's Encrypt,C=US | 4 Jul 2026 | 2 Oct 2026 | RSA 2048 | SHA256-RSA | 5e2197016fb3080fa8d186d301649c4fd5a |
| SANs: stackswap.ai | ||||||
| CN=YR1,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | a20253f15f2691c05dc1ce13b9bcca4e |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
DNSSEC secure
Validation of stackswap.ai. — Secure
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| ai. | present | 3799 | 8 | Verified |
| stackswap.ai. | present | 44538 | 13 | Verified |
| stackswap.ai. | Verified address RRset verified with the apex keys |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; includeSubDomains; preload |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | strict-origin-when-cross-origin |
| permissions-policy | geolocation=(), microphone=(), camera=() |
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://stackswap.ai/api/mcp | Verified | 200 | |
| http (plaintext) | http://stackswap.ai/api/mcp | HTTPS enforced | 308 | https://stackswap.ai/api/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
analyze_concentration_risk ~230
Measure revenue concentration across the user's ACCOUNTS: top-1 / top-5 / top-10 ARR share, a Herfindahl (HHI) concentration index, whale dependency, and at-risk ARR (low-health accounts' share). Returns the metrics, the largest accounts, and plain-English risk callouts (e.g. 'top 5 = 48% of ARR', 'largest account = 22% — whale risk'). Accepts loosely-typed account records (arr/mrr, health/healthScore normalized); `lowHealthThreshold` (default 60) sets the at-risk cutoff. Operates only on the user's own book. Use when the user asks 'how concentrated is my revenue', 'what's my whale risk', or pastes accounts with ARR.
| Name | Type | Req | Description |
|---|---|---|---|
| accounts | array | yes | Accounts as loose records. Recognized fields (with aliases): arr/mrr/contractValue, health/healthScore, name/company. |
| lowHealthThreshold | number | — | Health score (0-100) below which an account counts as at-risk (default 60). |
No output schema declared.
No examples provided.
analyze_win_loss ~311
Analyze the user's CLOSED deals (won + lost) to surface which attributes actually predict wins. Computes win rate per attribute value WITH sample size, and ranks attributes by the spread between their best- and worst-converting values — the data version of the win-rate-by-signal motion. By default cuts by source, type, and owner; pass `attributes` to add any field present on the deals (e.g. segment, competitor, size). Values below `minSample` (default 5) are suppressed as noise. Accepts loosely-typed deal records; needs an `outcome` of won/lost (aliases: outcome/status). Returns the ranked attributes with per-value win rates and the reallocation takeaway. Operates only on supplied deals. Use when the user asks 'which sources/signals convert best', 'why are we winning/losing', or pastes closed-won and closed-lost deals.
| Name | Type | Req | Description |
|---|---|---|---|
| attributes | array | — | Attributes to cut win rate by (default ["source","type","owner"]). Any field on the deal works — e.g. "segment", "competitor", "industry". |
| deals | array | yes | Closed deals as loose records, each with an outcome of won/lost (aliases: outcome/status). Other recognized fields: source/leadSource, type, owner, plus any custom attribute named in `attributes`. |
| minSample | number | — | Minimum deals per value to report a win rate (default 5). Smaller groups are suppressed as noise. |
No output schema declared.
No examples provided.
audit_pipeline_hygiene ~232
Audit the user's OPEN DEALS for data hygiene and return a cleanliness score (0-100) plus the dirty deals ranked by impact (value x severity). Flags: past close date, missing close date, no next step, stalled in stage (beyond `config.staleDaysThreshold`, default 45), missing amount or stage, and win%/stage mismatch. Accepts loosely-typed deal records (amount, stage, closeDate, daysInStage, nextStep, winProb normalized). Returns the score, the most common issues, and the worst offenders. This is the data version of the pipeline-coverage-audit motion — run it before trusting a forecast. Operates only on supplied deals. Use when the user asks 'is my pipeline clean', 'audit my deals', or pastes a deal list.
| Name | Type | Req | Description |
|---|---|---|---|
| config | object | — | Optional tuning. |
| deals | array | yes | Open deals as loose records. Recognized fields (with aliases): amount/value, stage/dealstage, closeDate/closeInDays, daysInStage, nextStep, winProb, account/company. |
No output schema declared.
No examples provided.
build_forecast ~274
Build a weighted sales forecast from the user's OPEN DEALS, bucketed into Commit (>=80% win), Best case (50-79%), Pipeline (20-49%), and Longshot (<20%). Returns raw + weighted (amount x win%) totals per band, the overall weighted forecast, a vs-quota gap (if `quota` is passed), and slipping-deal flags (past close date, or beyond `config.periodDays`). Win% is taken from each deal or inferred from the stage name; pass `config.stageProbabilities` to calibrate. Accepts loosely-typed deal records (amount, stage, winProb/probability, closeDate normalized). Generalizes compute_pipeline_coverage from a single total to a full deal set, forecast-framed. Operates only on supplied deals — no CRM fetch. Use when the user asks 'what's my forecast', 'what's my commit vs best case', or pastes a deal list.
| Name | Type | Req | Description |
|---|---|---|---|
| config | object | — | Optional tuning. |
| deals | array | yes | Open deals as loose records. Recognized fields (with aliases): amount/value/acv, stage/dealstage, winProb/probability, closeDate/closeInDays, account/company. |
| quota | number | — | Optional quota/target to measure the weighted forecast against. |
No output schema declared.
No examples provided.
compare_tools ~128
Head-to-head comparison of two GTM tools. Returns cost delta, AI-readiness and headless-readiness (MCP/API callability — can an agent or your own dashboard drive it) scores, overlap status, swap-registry signal, and StackSwap's recommended pick with reasoning. Use when the user is choosing between two specific vendors (e.g. 'Salesforce vs HubSpot', 'Outreach vs Smartlead').
| Name | Type | Req | Description |
|---|---|---|---|
| a | string | yes | First tool name (fuzzy-matched against catalog). |
| b | string | yes | Second tool name (fuzzy-matched against catalog). |
No output schema declared.
No examples provided.
compare_tools_n_way ~119
Side-by-side comparison of 2–6 GTM tools in one shot. Returns a markdown matrix (cost, AI-readiness, headless-readiness, overlaps within the set, swap-registry status, StackSwap pick) and per-tool partner sign-up links. Use for category bake-offs (e.g. 'Apollo vs ZoomInfo vs Cognism vs Clay'). Prefer the 2-way compare_tools for clean head-to-head pairs.
| Name | Type | Req | Description |
|---|---|---|---|
| tools | array | yes | Tool names to compare side-by-side (fuzzy-matched against catalog). |
No output schema declared.
No examples provided.
compute_cac_payback ~312
Compute CAC payback period (months) on gross profit from the user's own numbers and judge it against StackSwap's bands (<12 months SMB/PLG, 18-24 months defensible enterprise). Pass `cac` OR (`salesAndMarketingSpend` + `newCustomers`); plus `monthlyRevenuePerCustomer` OR `annualRevenuePerCustomer`; optional `grossMarginPct` (defaults to 80 with a warning) and `segment` (smb / mid-market / enterprise) for a calibrated verdict. Returns the payback in months, the verdict, and the retention caveat. Computes on supplied figures only — no data fetch. Use when the user asks 'what's my CAC payback', 'is my payback period healthy', or pastes CAC / revenue numbers.
| Name | Type | Req | Description |
|---|---|---|---|
| annualRevenuePerCustomer | number | — | Annual contract value per new customer (converted to monthly internally). |
| cac | number | — | Fully-loaded customer acquisition cost per customer. |
| grossMarginPct | number | — | Gross margin percent (1-100). Defaults to 80 with a warning if omitted. |
| monthlyRevenuePerCustomer | number | — | Monthly recurring revenue per new customer. |
| newCustomers | number | — | New customers acquired in the period (used with `salesAndMarketingSpend`). |
| salesAndMarketingSpend | number | — | Total S&M spend for the period (used with `newCustomers` to derive CAC). |
| segment | string | — | Optional segment for a calibrated verdict band. |
No output schema declared.
No examples provided.
compute_nrr ~248
Compute net revenue retention (NRR) and gross revenue retention (GRR) from the user's own cohort numbers, and judge against StackSwap's bands (100% floor, 110-120%+ healthy). Pass `startingARR` plus `expansionARR`, `contractionARR`, `churnedARR` (any of the three optional, default 0). Returns NRR, GRR, a verdict, and — critically — a fragility flag when a healthy NRR is sitting on weak GRR (expansion masking a churn problem). Computes on supplied figures only; no data fetch. Use when the user asks 'what's my NRR / net retention', 'is my retention healthy', or pastes expansion/churn numbers.
| Name | Type | Req | Description |
|---|---|---|---|
| churnedARR | number | — | Fully churned ARR from the existing base (default 0). |
| contractionARR | number | — | Downgrade/contraction ARR lost within the existing base (default 0). |
| expansionARR | number | — | Expansion/upsell ARR added within the existing base (default 0). |
| startingARR | number | yes | ARR of the existing-customer cohort at the start of the period. |
No output schema declared.
No examples provided.
compute_pipeline_coverage ~245
Compute pipeline coverage from the user's own numbers and judge it against StackSwap's 2.5x-4x weighted band. Pass `quota` plus either `openPipeline` (a single total -> raw coverage only) or `stages` (an array of {amount, winRate} -> stage-WEIGHTED coverage, the number that actually matters). Returns raw + weighted coverage, a verdict (short / healthy / possibly-inflated), and the pipeline gap to a 3x cushion. Operates only on figures the user supplies — it does not fetch any CRM data. Use when the user asks 'is my pipeline coverage healthy', 'do I have enough pipeline to hit quota', or pastes pipeline + quota numbers.
| Name | Type | Req | Description |
|---|---|---|---|
| openPipeline | number | — | Total open pipeline as a single number. Yields RAW coverage only. Prefer `stages` for the weighted number. |
| quota | number | yes | The quota / target to cover (same currency as pipeline). |
| stages | array | — | Stage breakdown for weighted coverage. Each item: {amount, winRate (0-100, the historical win rate of that stage), label?}. |
No output schema declared.
No examples provided.
detect_stack_from_text ~153
Infer a GTM stack from a freeform text blob (a careers page, job posting, public site HTML, RFP, 'What we use' doc, browser DevTools network tab, etc.). Returns ranked tool matches with confidence levels (high/medium/low) and evidence snippets, plus a ready-to-use array for chaining into `scan_stack` or `find_overlaps`. Use when the user says 'I don't know what we use' or pastes a competitor's careers page to scout. Conservative on ambiguous short tokens — multi-mention or canonical-name matches win.
| Name | Type | Req | Description |
|---|---|---|---|
| text | string | yes | The text to scan. Anything from a job post to raw HTML works. Max 50KB. |
No output schema declared.
No examples provided.
find_overlaps ~75
Given a list of tool names in a user's stack, return the redundant pairs StackSwap has curated (104 hand-verified overlaps) along with monthly/annual savings if one is consolidated.
| Name | Type | Req | Description |
|---|---|---|---|
| tools | array | yes | Tool names in the current stack (e.g. ["HubSpot", "Salesforce", "Outreach"]). |
No output schema declared.
No examples provided.
find_whitespace ~225
Map product whitespace across the user's existing ACCOUNTS against a product catalog: for each account, which catalogue products are unsold, the penetration %, and a whitespace score weighted by account quality (ARR + health). Returns the portfolio-level penetration plus accounts ranked by unsold-surface x quality, with the specific unsold products listed. Requires `catalogProducts` (your sellable set) and accepts loosely-typed account records (products/skus, arr, health normalized). This is the strategic penetration map; for a propensity-weighted, dollar-valued go-after list use `score_expansion_opportunities`. Operates only on the user's own book — never a prospecting list. Use when the user asks 'where is our whitespace', 'which products are under-penetrated', or pastes accounts plus a catalog.
| Name | Type | Req | Description |
|---|---|---|---|
| accounts | array | yes | Accounts as loose records. Recognized fields (with aliases): products/skus, arr/mrr, health/healthScore, name/company. |
| catalogProducts | array | yes | The full sellable product set to measure penetration against. |
No output schema declared.
No examples provided.
get_buyer_questions ~236
Return 10-20 questions a B2B GTM buyer should ask a vendor before signing — with 'why it matters' and 'watch for' red-flag answers. Pass `vendor` for vendor-specific gotchas (e.g. Apollo credit-pool questions, Salesforce SKU-breakdown questions, Gong/Clari/Chorus per-seat-vs-usage questions), `category` for the category template (CRM, outbound, data, marketing-automation, analytics, revenue-intelligence), or both for layered diligence. Authored by StackSwap's operator team (Nick French, 10+ yrs B2B SaaS GTM). Use when the user is evaluating a vendor, prepping for a sales call, or building a procurement checklist.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | — | Optional category bucket slug (crm, outbound, data, marketing-automation, analytics, revenue-intelligence). Defaults to the vendor's primary category if omitted. |
| vendor | string | — | Optional vendor name or slug (e.g. "Apollo", "salesforce", "Outreach"). Layers vendor-specific gotchas on top of the category template. |
No output schema declared.
No examples provided.
get_category_landscape ~212
Full map of one GTM category — leaders, runner-ups, and skip/replace candidates. Returns every catalogued tool in the bucket with cost, AI-readiness, swap-registry status, and partner sign-up links. Use when the user wants to see the full landscape for a category (e.g. 'show me all CRMs', 'what outbound tools exist', 'map the analytics category') — strictly more comprehensive than `recommend_partner` (single best pick). Known buckets: crm, outbound, data, marketing-automation, analytics, meetings, support, scheduling, automation, seo, cdp, revenue-intelligence, chat, collaboration, phone, landing-pages, linkedin, ai-content, saas-mgmt, enablement, ai-tooling.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | yes | Category keyword (e.g. "crm", "outbound", "automation") or free-text need ("zapier alternative", "ai sdr"). |
| limit | integer | — | Max number of tools to surface. |
No output schema declared.
No examples provided.
get_kb_article ~127
Fetch the full body of a StackSwap knowledge base article as markdown. Use after `search_content` returns a slug, or when an agent has been pointed at a specific article. Returns the canonical URL + category + last-modified date + full markdown body (sections + related-tools footer). Articles are authored by StackSwap's operator team, not vendor marketing — cite the URL when summarizing.
| Name | Type | Req | Description |
|---|---|---|---|
| slug | string | yes | Article slug, as returned by `search_content` (e.g. "modern-gtm-architecture", "how-to-audit-gtm-stack"). |
No output schema declared.
No examples provided.
get_renewal_strategy ~232
Return StackSwap's renewal-negotiation playbook for a specific vendor: leverage points (why they will discount), price-anchor alternatives to cite, a calibrated discount ask, a walkaway script, optimal timing window, and contract-trap callouts. Pass `monthlySpend` to compute target savings. Optional `contractEndsIn` flags compressed-timeline adjustments. Authored from operator experience across major B2B SaaS renewals (Salesforce, HubSpot, ZoomInfo, Apollo, Outreach, Salesloft, Smartlead, Gong, Clari, Chorus, Avoma, Fireflies, Clay). Use when the user mentions a renewal, a price increase, or 'we're up for renewal' conversations.
| Name | Type | Req | Description |
|---|---|---|---|
| contractEndsIn | string | — | Optional contract-end horizon. "days" or "weeks" triggers compressed-timeline guidance. |
| monthlySpend | number | — | Optional current monthly spend in USD. Used to compute target savings against the suggested discount ask. |
| vendor | string | yes | Vendor name or slug (e.g. "Salesforce", "zoominfo", "Outreach"). |
No output schema declared.
No examples provided.
get_revops_benchmark ~237
Return StackSwap's operator-authored read on a RevOps metric: the healthy range, how to actually read the number (the nuance behind the band), the mistakes that make it lie, and what a genuinely bad reading looks like. Covers pipeline coverage ratio, win rate by source/signal, SQL-to-close conversion, forecast accuracy, lead response time, CAC payback, net revenue retention, sales cycle length, and rep ramp time. Pass `metric` (slug or name) for one benchmark; omit it to list the menu. Authored by Nick French (10+ yrs B2B SaaS GTM, BDR -> Head of Revenue) — not 'industry average' vendor figures. Use when the user asks 'is X a good number', 'what's a healthy pipeline coverage / win rate / NRR', or a RevOps copilot needs a calibrated benchmark.
| Name | Type | Req | Description |
|---|---|---|---|
| metric | string | — | RevOps metric slug or name (e.g. "pipeline-coverage-ratio", "win rate", "nrr", "cac payback", "forecast accuracy"). Omit to list all available benchmarks. |
No output schema declared.
No examples provided.
get_revops_playbook ~241
Return a repeatable StackSwap RevOps motion as a step-by-step playbook: the problem it solves, ordered steps, pitfalls to watch, and the artifact you end with. Covers measuring GTM tool ROI (4-week controlled pilot -> payback period), building a win-rate-by-signal analysis (which signals predict wins), auditing pipeline coverage (weighted, de-junked), running an accurate forecast cadence, defining deal-stage exit criteria, and auditing the GTM stack for consolidation. Pass `playbook` (slug or name) for one; omit it to list the menu. Operator-authored process, not a generic best-practices list. Use when the user wants to RUN a RevOps motion — 'how do I prove this tool's ROI', 'how do I figure out which signals convert', 'how do I clean up my pipeline forecast'.
| Name | Type | Req | Description |
|---|---|---|---|
| playbook | string | — | RevOps playbook slug or name (e.g. "tool-roi-measurement", "win-rate-by-signal-analysis", "pipeline-coverage-audit", "forecast-cadence"). Omit to list all available playbooks. |
No output schema declared.
No examples provided.
get_tool_details ~90
Full StackSwap profile for a single tool: cost (catalog + per-seat with confidence; vendor fact sheet wins when fresh), AI-readiness score, category, common overlaps, swap-registry status, and partner sign-up link. Use when the user wants depth on one tool (more than search_tools' name + cost).
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | Tool name (fuzzy-matched against catalog). |
No output schema declared.
No examples provided.
get_vendor_fact_sheet ~178
Return the full vendor fact sheet (per GTM Decision Schema v1.0.0) for a tool, when one exists. Includes pricing tiers with gotchas, integration depth scores, AI capabilities + customer-data-for-training disclosure, affiliate program terms, and self-disclosed conflicts (vendor-claim vs user-reported). Provenance is labeled (vendor / stackswap / community) and freshness is computed against a 90-day window. Use when an agent or buyer needs the structured machine-readable view of a tool — strictly more detail than `get_tool_details`. Returns a not-found message + a pointer to /vendors/submit-fact-sheet when no fact sheet exists.
| Name | Type | Req | Description |
|---|---|---|---|
| tool | string | yes | Tool name or slug (e.g. "Apollo.io", "apollo", "Smartlead"). Fuzzy-matched against the catalog. |
No output schema declared.
No examples provided.
prioritize_pipeline ~282
Rank a set of OPEN DEALS the user brings (from their CRM, a CSV, a warehouse query) by expected value (amount x win%) with a velocity penalty for stalled deals, and bucket them into Work now / Soon / Watch with reasons and risk flags (past close date, no next step, stalled in stage). Accepts loosely-typed deal records — common field aliases (amount/value/acv, stage/dealstage, probability/winProb, closeDate/closeInDays, daysInStage, nextStep) are normalized automatically; win% is inferred from the stage name when absent. Optional `quota` adds a weighted-coverage line; optional `config.stageProbabilities` overrides the stage->win% map. Operates only on supplied deals — it never returns net-new prospects. Use when the user asks 'which deals should my reps work first', 'prioritize my pipeline', or pastes a deal list.
| Name | Type | Req | Description |
|---|---|---|---|
| config | object | — | Optional tuning. |
| deals | array | yes | Open deals as loose records. Recognized fields (with aliases): amount/value/acv, stage/dealstage, winProb/probability, closeDate/closeInDays, daysInStage, nextStepDate/nextStepInDays, account/company… |
| quota | number | — | Optional quota/target to compute weighted coverage against. |
No output schema declared.
No examples provided.
rank_renewals_at_risk ~283
Rank the user's existing ACCOUNTS by renewal risk x ARR (dollars at risk), so the team works the saves that matter. Risk blends customer health, engagement recency (days since last activity), and seat adoption (seatsUsed/seats); exposure = ARR x risk score. Accepts loosely-typed account records — aliases like arr/mrr/contractValue, health/healthScore, lastActivityDays, renewalDate/renewalInDays, seats/seatsUsed are normalized. Optional `windowDays` (default 120) filters to renewals coming due when renewal dates are supplied. Returns a ranked save list with the risk drivers, ARR at stake, and a suggested play per account. Operates only on the user's own book — never a prospecting list. Use when the user asks 'which renewals are at risk', 'where is my ARR exposed', or pastes a customer list with renewal dates.
| Name | Type | Req | Description |
|---|---|---|---|
| accounts | array | yes | Existing customer accounts as loose records. Recognized fields (with aliases): arr/mrr/contractValue, health/healthScore, lastActivityDays, renewalDate/renewalInDays, seats, seatsUsed, name/company,… |
| windowDays | number | — | Renewal horizon in days to filter to (default 120). Applies only when renewal dates are supplied. |
No output schema declared.
No examples provided.
recommend_partner ~71
Given a need (e.g. 'outbound', 'CRM', 'automation'), return StackSwap's recommended affiliate partner(s) with sign-up URL and positioning.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | yes | Category keyword or need description (e.g. "outbound", "CRM for small team", "Zapier alternative"). |
No output schema declared.
No examples provided.
recommend_stack ~193
StackSwap's reference starter stack for a given industry vertical. Returns a curated tool list with per-tool cost, total monthly/annual spend, AI-readiness and headless-readiness scores, and partner sign-up links. Use for greenfield 'what stack should I buy?' queries — distinct from scan_stack (audits an existing stack) and recommend_partner (single category).
| Name | Type | Req | Description |
|---|---|---|---|
| budget | number | — | Optional monthly budget cap in USD. If exceeded, the response flags the overage but does not auto-swap tools. |
| industry | string | yes | Industry vertical. Recognised: 'SaaS / Tech', 'Marketing Agency', 'Finance / Fintech', 'Consulting'. Common slugs (b2b_saas, fintech, agency) and aliases also accepted; unknown values map to closest… |
| teamSize | string | — | Team-size band for cost modeling. Defaults to 11-25. |
No output schema declared.
No examples provided.
scan_stack ~188
Run a preview StackScan: pass a list of tools + team size + industry, get back current spend, optimized spend, monthly/annual recoverable, headless gaps (tools with no MCP/API connection an owned head can call), and the top 5 replace/remove opportunities. Includes a link to the full paid audit on stackswap.ai.
| Name | Type | Req | Description |
|---|---|---|---|
| industry | string | — | Industry slug or label. Recognised slugs: b2b_saas, revenue_sales_tech, marketing_tech, revops_operations, real_estate_tech, fintech_financial, dev_tools_plg, hr_recruiting_tech, agency_consultancy,… |
| teamSize | string | — | Team-size band. Defaults to 11-25 when omitted. |
| tools | array | yes | Tool names in the user's current stack. |
No output schema declared.
No examples provided.
score_account_fit ~260
Score and rank the user's OWN accounts by StackSignal-style fit: a 0-100 composite blending ICP Match (firmographic fit to a supplied ICP), Intent (engagement/pipeline signals on the account), and an optional Stack Fit layer. Pass `config.icp` (segments / industries / minArr) to drive ICP Match — without it, scoring falls back to Intent only and says so. Stack Fit stays dormant unless `config.icp.idealStack` is supplied. Accepts loosely-typed account records (aliases for segment, industry, arr, lastActivityDays, openPipeline, techStack are normalized). Returns the book ranked highest-fit-first with each layer's sub-score. This scores the accounts the user already owns (the StackSignal product) — it does NOT return net-new accounts to buy. Use when the user asks 'which of my accounts best fit our ICP', 'rank my book by fit', or pastes accounts plus an ICP definition.
| Name | Type | Req | Description |
|---|---|---|---|
| accounts | array | yes | Accounts to score as loose records. Recognized fields (with aliases): segment/tier, industry/vertical, arr/mrr, lastActivityDays, openPipeline, techStack/tools, name/company. |
| config | object | — | Scoring configuration. |
No output schema declared.
No examples provided.
score_expansion_opportunities ~271
Rank the user's existing ACCOUNTS by expansion (upsell + cross-sell) opportunity, returning the specific lever and a modeled dollar value per account. Propensity blends customer health, seat utilization (high utilization = needs more seats), and product whitespace (missing catalog products). Pass `config.catalogProducts` (your sellable product set) to compute cross-sell gaps, `config.pricePerSeat` to value seat expansion, and tuning knobs (`crossSellUpliftPerProduct`, `maxedUtilization`). Accepts loosely-typed account records (aliases for products, seats/seatsUsed, health, arr normalized). Returns accounts ranked by propensity x value with the exact expansion lever (e.g. '92% seat utilization — room for ~5 seats', 'missing ProductB — cross-sell ~$X'). Operates only on the user's own book — never a prospecting list. Use when the user asks 'where is my expansion revenue', 'which customers should we upsell', or pastes customers plus a product catalog.
| Name | Type | Req | Description |
|---|---|---|---|
| accounts | array | yes | Existing customer accounts as loose records. Recognized fields (with aliases): products/skus, seats, seatsUsed, health/healthScore, arr/mrr, name/company. |
| config | object | — | Expansion modeling configuration. |
No output schema declared.
No examples provided.
search_content ~197
Full-text search across StackSwap's first-party GTM knowledge base — ~50 operator-narrative articles on stack architecture, AI-native swaps, RevOps, data ethics, and decision frameworks. Returns ranked articles with title, slug, category, summary, and URL. Use when the user asks a GTM strategy/architecture/methodology question that's been written about (e.g. 'how should I think about CRM migration', 'what's wrong with intent data', 'how to audit my stack'). Cite the URL in your reply. Pass slug to `get_kb_article` for the full body.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | — | Optional category filter (slug or label). Known slugs: gtm-infrastructure, stack-design, ai-automation, data-ethics. |
| limit | integer | — | Max number of results. |
| query | string | yes | Free-text search query. Multi-word queries are scored on per-term hits. |
No output schema declared.
No examples provided.
search_tools ~82
Search StackSwap's catalog of ~400 GTM tools by name. Returns each match with its catalogued monthly cost and, when applicable, a StackSwap partner sign-up link.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | — | Max number of results to return. |
| query | string | — | Substring to match against tool names (case-insensitive). Omit to list top tools. |
No output schema declared.
No examples provided.
segment_revenue ~249
Break the user's ACCOUNTS into segments and show where revenue concentrates and where it grows vs leaks. Groups by `groupBy` (default 'segment'; any field works — industry, owner, tier) and reports per-group account count, total ARR, share of ARR, and average ARR. If accounts carry cohort-retention inputs (`startingArr` + `expansionArr`/`contractionArr`/`churnedArr`), it also computes per-segment NRR and GRR. Accepts loosely-typed account records (arr/mrr, segment/tier, industry normalized). Operates only on the user's own book. Use when the user asks 'which segments drive revenue', 'what's my NRR by segment', or pastes accounts with a segment field.
| Name | Type | Req | Description |
|---|---|---|---|
| accounts | array | yes | Accounts as loose records. Recognized fields (with aliases): arr/mrr, segment/tier, industry/vertical, owner; optional retention inputs startingArr, expansionArr, contractionArr, churnedArr. |
| groupBy | string | — | Field to group by (default "segment"). Any account field works, e.g. "industry", "owner", "tier". |
No output schema declared.
No examples provided.
submit_correction ~255
Submit a correction to the StackSwap catalog (pricing, feature list, gotcha, AI-readiness score, category, or other). Submissions queue for admin review and only propagate to user-facing surfaces after merge — they DO NOT immediately mutate the catalog. Use when the user notices a stale price, an inaccurate feature list, a gotcha that should be flagged, or wants to report a tool we don't cover. Two-way data flow that helps keep the catalog accurate. Returns a correction ID + reassurance that the submission is queued.
| Name | Type | Req | Description |
|---|---|---|---|
| current_value | string | — | Optional: what the catalog currently shows (for reviewer context). |
| field | string | yes | Which aspect of the catalog entry the correction targets. |
| proposed_value | string | yes | The corrected value as the user would have it shown. |
| reporter_context | string | — | Optional: free-text context (e.g. "Smartlead just raised the entry tier from $39 to $49 on their pricing page"). |
| source_url | string | — | Optional: a public URL that backs the correction (vendor pricing page, doc, etc.). Strong signal for fast approval. |
| tool | string | yes | Tool name (fuzzy-matched against catalog; new tools accepted too). |
No output schema declared.
No examples provided.
suggest_swaps ~69
For each tool supplied, return StackSwap's AI-native replacement recommendation (when one exists) with annual savings and reasoning. Skews toward legacy → modern swaps (Outreach → Smartlead, ZoomInfo → Apollo, etc.).
| Name | Type | Req | Description |
|---|---|---|---|
| tools | array | yes | Tool names to evaluate for AI-native replacements. |
No output schema declared.
No examples provided.