Sales Stack Router

Most teams now have more than one sales-engagement MCP server connected — Outreach, Salesloft, Apollo, plus whatever else got added along the way. Nothing decides which one should handle a given request. The two default behaviors are both bad: hardcode one tool (breaks the moment that tool is rate-limited or the account changes), or call every connected tool and let the user sort out duplicate results.

This skill is the missing decision layer. Give it a request (e.g. “enrich this contact”) and a live manifest of what’s connected — built to the MCP Capability Manifest Schema — and it returns one ranked pick, a fallback chain, and the reasoning behind the choice.

How it works

const { route } = require('./router.js');
const result = route({ capability: 'contact.enrich', min_scope: 'read' }, manifests);

if (result.decision === 'route') {
  // call result.pick.server_id; retry against result.fallback_chain[0] on failure
} else if (result.decision === 'rate_limited') {
  // every capable server is over its limit — wait result.retry_after_seconds
} else {
  // 'no_capable_server' — nothing connected can do this
}

Destructive actions require an explicit opt-in

Every capability declares a required_scope of read, write, or destructive. By default, destructive capabilities (deleting a prospect, purging a sequence) are never routed unless the caller explicitly passes allow_destructive: true. Same governance principle MV3 applies to its own MU-plugin deploys — destructive actions need an explicit opt-in, not an implicit one.

What it does NOT do

It never calls any API itself — a pure decision function, zero network calls, zero dependencies. You still own the actual MCP tool call; this tells you which server to call and why. It also holds no state between calls, so it stays safe to run inside any orchestration loop.