# StackSwap (remote · stackswap.ai)

B2B GTM stack intelligence: search ~400 tools, compare vendors, find overlaps, audit SaaS spend.

- Trust score: 66/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `stackswap.ai`: 66/100 (this document), [markdown](https://verifymcp.io/servers/stonesofcreation-stackswap/api-mcp.md), [page](https://verifymcp.io/servers/stonesofcreation-stackswap/api-mcp)

## Channel facts

- Endpoint: `https://stackswap.ai/api/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.1.0`

## Trust breakdown

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. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 66/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - 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.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC is configured correctly; the domain's records validate against the full chain to the root.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 61/100
  - AI-judged instruction clarity (excellent).
  - 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.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 60/100
  - Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http stonesofcreation-stackswap https://stackswap.ai/api/mcp
```

### Codex

```toml
[mcp_servers.stonesofcreation-stackswap]
url = "https://stackswap.ai/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "stonesofcreation-stackswap": {
      "type": "remote",
      "url": "https://stackswap.ai/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add stonesofcreation-stackswap --url https://stackswap.ai/api/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  stonesofcreation-stackswap:
    url: "https://stackswap.ai/api/mcp"
```

### Other

```json
{
  "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.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 66, +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.

### 2026-08-01 (score 65, +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.

### 2026-07-31 (score 64, +2)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 62, −2)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 64, +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.

### 2026-07-28 (score 63, +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.

### 2026-07-27 (score 62, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 62)

First indexed and scored.

## MCP tools (32)

### `search_tools` (~82 tokens)

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.

Input parameters:

- `limit` (integer): Max number of results to return.
- `query` (string): Substring to match against tool names (case-insensitive). Omit to list top tools.

### `get_tool_details` (~90 tokens)

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

Input parameters:

- `name` (string, required): Tool name (fuzzy-matched against catalog).

### `get_vendor_fact_sheet` (~178 tokens)

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.

Input parameters:

- `tool` (string, required): Tool name or slug (e.g. "Apollo.io", "apollo", "Smartlead"). Fuzzy-matched against the catalog.

### `find_overlaps` (~75 tokens)

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.

Input parameters:

- `tools` (array, required): Tool names in the current stack (e.g. ["HubSpot", "Salesforce", "Outreach"]).

### `suggest_swaps` (~69 tokens)

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

Input parameters:

- `tools` (array, required): Tool names to evaluate for AI-native replacements.

### `scan_stack` (~188 tokens)

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.

Input parameters:

- `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, required): Tool names in the user's current stack.

### `recommend_partner` (~71 tokens)

Given a need (e.g. 'outbound', 'CRM', 'automation'), return StackSwap's recommended affiliate partner(s) with sign-up URL and positioning.

Input parameters:

- `category` (string, required): Category keyword or need description (e.g. "outbound", "CRM for small team", "Zapier alternative").

### `recommend_stack` (~193 tokens)

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

Input parameters:

- `budget` (number): Optional monthly budget cap in USD. If exceeded, the response flags the overage but does not auto-swap tools.
- `industry` (string, required): 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.

### `compare_tools` (~128 tokens)

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').

Input parameters:

- `a` (string, required): First tool name (fuzzy-matched against catalog).
- `b` (string, required): Second tool name (fuzzy-matched against catalog).

### `compare_tools_n_way` (~119 tokens)

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.

Input parameters:

- `tools` (array, required): Tool names to compare side-by-side (fuzzy-matched against catalog).

### `search_content` (~197 tokens)

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.

Input parameters:

- `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, required): Free-text search query. Multi-word queries are scored on per-term hits.

### `get_kb_article` (~127 tokens)

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.

Input parameters:

- `slug` (string, required): Article slug, as returned by `search_content` (e.g. "modern-gtm-architecture", "how-to-audit-gtm-stack").

### `get_category_landscape` (~212 tokens)

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.

Input parameters:

- `category` (string, required): Category keyword (e.g. "crm", "outbound", "automation") or free-text need ("zapier alternative", "ai sdr").
- `limit` (integer): Max number of tools to surface.

### `detect_stack_from_text` (~153 tokens)

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.

Input parameters:

- `text` (string, required): The text to scan. Anything from a job post to raw HTML works. Max 50KB.

### `get_buyer_questions` (~236 tokens)

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.

Input parameters:

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

### `get_renewal_strategy` (~232 tokens)

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.

Input parameters:

- `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, required): Vendor name or slug (e.g. "Salesforce", "zoominfo", "Outreach").

### `get_revops_benchmark` (~237 tokens)

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.

Input parameters:

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

### `get_revops_playbook` (~241 tokens)

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

Input parameters:

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

### `compute_pipeline_coverage` (~245 tokens)

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.

Input parameters:

- `openPipeline` (number): Total open pipeline as a single number. Yields RAW coverage only. Prefer `stages` for the weighted number.
- `quota` (number, required): 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?}.

### `compute_cac_payback` (~312 tokens)

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.

Input parameters:

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

### `compute_nrr` (~248 tokens)

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.

Input parameters:

- `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, required): ARR of the existing-customer cohort at the start of the period.

### `prioritize_pipeline` (~282 tokens)

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.

Input parameters:

- `config` (object): Optional tuning.
- `deals` (array, required): 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.

### `rank_renewals_at_risk` (~283 tokens)

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.

Input parameters:

- `accounts` (array, required): 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.

### `score_account_fit` (~260 tokens)

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.

Input parameters:

- `accounts` (array, required): 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.

### `score_expansion_opportunities` (~271 tokens)

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.

Input parameters:

- `accounts` (array, required): 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.

### `find_whitespace` (~225 tokens)

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.

Input parameters:

- `accounts` (array, required): Accounts as loose records. Recognized fields (with aliases): products/skus, arr/mrr, health/healthScore, name/company.
- `catalogProducts` (array, required): The full sellable product set to measure penetration against.

### `build_forecast` (~274 tokens)

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.

Input parameters:

- `config` (object): Optional tuning.
- `deals` (array, required): 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.

### `analyze_win_loss` (~311 tokens)

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.

Input parameters:

- `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, required): 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.

### `segment_revenue` (~249 tokens)

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.

Input parameters:

- `accounts` (array, required): 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".

### `analyze_concentration_risk` (~230 tokens)

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.

Input parameters:

- `accounts` (array, required): 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).

### `audit_pipeline_hygiene` (~232 tokens)

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.

Input parameters:

- `config` (object): Optional tuning.
- `deals` (array, required): Open deals as loose records. Recognized fields (with aliases): amount/value, stage/dealstage, closeDate/closeInDays, daysInStage, nextStep, winProb, account/company.

### `submit_correction` (~255 tokens)

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.

Input parameters:

- `current_value` (string): Optional: what the catalog currently shows (for reviewer context).
- `field` (string, required): Which aspect of the catalog entry the correction targets.
- `proposed_value` (string, required): 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, required): Tool name (fuzzy-matched against catalog; new tools accepted too).

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/stonesofcreation-stackswap/api-mcp#diagnostics

## Score history

- 2026-08-03: 66
- 2026-08-02: 65
- 2026-08-01: 65
- 2026-07-31: 64
- 2026-07-30: 62
- 2026-07-29: 64
- 2026-07-28: 63
- 2026-07-27: 62
- 2026-07-26: 62

## Links

- Remote endpoint: https://stackswap.ai/api/mcp
- Repository: https://github.com/StonesofCreation/stackswap-mcp
- Website: https://stackswap.ai/mcp
- Changelog RSS feed: https://verifymcp.io/servers/stonesofcreation-stackswap/api-mcp/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/stonesofcreation-stackswap/api-mcp/changelog.json
- HTML version of this page: https://verifymcp.io/servers/stonesofcreation-stackswap/api-mcp