Last Friday I attended a startup event where the speaker Prem Kumar shared his outbound experiences and his process - a battle-tested methodology from Revmaze, showcased at the SaaSBoomi GTM Scars roundtable.

The playbook is aimed at -1 to 0 founders, those who haven't found product-market fit yet and need to find their first 30 customers through raw, personal outbound. Not 3,000 leads from a database dump. 30 companies, each with a researched reason to reach out.

Prem documented his playbook and shared it with us Monday, 9th March. Tejas Pandit, who shared excellent insights from his own startup journey, nudged us participants to see if we can make it an MCP server.

So, here we are Tuesday, 10th March, a baby version of the Outbound Playbook MCP Server is ready. Prem's knowledge packaged now for entrepreneurs everywhere!

Why This Playbook Caught My Eye

I've been in IT for 26 years. Built NLP products, ran a company for 13 years. The one thing that never changes is how hard it is to get the first few customers. Every founder I know, including myself, has stared at the "how do I find people who will pay for this?" question.

Prem's playbook doesn't hand-wave. It gives you:

  • A 4-line email framework (OPPS — Observation, Problem, P.S., Simple CTA)
  • A 4-message LinkedIn DM sequence
  • A 6-step cold call script with a "problem stack" that earns credibility
  • A voicemail script that drives people to your email
  • A 14-day multi-channel sequence that ties all four together
  • Objection handling for the six most common pushbacks

Every framework has been tested across 50+ campaigns. The examples use real verticals — compliance/regtech, ecommerce, CLM, wealth management. This isn't theory. It's what actually works in the field.

But here's the thing, the playbook is a document. A very good document. And documents sit in folders.

The Question: Can an AI Co-Pilot Run This Playbook?

The playbook's workflow is fundamentally conversational. You're constantly context-switching:

  • "I just found a signal about this company"
  • "Draft me an email for them"
  • "What should I do today?"
  • "I called James, he said bad timing"

That's not a dashboard problem. That's a conversation problem. And conversations are exactly what Claude is good at. Solivitur Colloquendo!

The missing piece is state. Claude can draft an OPPS email if you give it the framework. But it can't remember that you're on Day 5 with James, that he opened your email twice (hot signal, call him!), and that Rachel at Metro Finance accepted your LinkedIn connection yesterday (time to DM).

An MCP server gives Claude that persistent memory. The frameworks live in the code. The campaign state lives in SQLite. Claude becomes the interface.

What I Built

An MCP server called outbound-playbook with 11 tools across four groups:

Campaign Management - Create campaigns with a thesis statement ("I believe companies with [signal] in [segment] have [problem] right now"), track them through their lifecycle.

Prospect Tracking - Add your 30 companies with their signal, observation, pain language, and tier. Tier 1 (top 10) gets email + LinkedIn + cold calls. Tier 2 (next 20) gets email only, with engagers escalated to calls.

The Brain - This is the core. get_today_actions computes the 14-day sequence for every active prospect and returns a prioritized action list. Someone opened your email twice? That's a high-priority call. LinkedIn connection accepted on Day 3? Time for a DM. Day 14 with no response? Send the breakup email (which, counterintuitively, gets the most replies).

Content Drafting - Given a prospect, generates all four channel variants from the same observation. One research session powers your email, LinkedIn DM, call script, and voicemail. The playbook's exact frameworks are baked in.

The whole thing is local-first. SQLite database, stdio transport, no external APIs. Your campaign data never leaves your machine.

The Stack

Nothing exotic:

  • Node.js + TypeScript
  • MCP SDK (@modelcontextprotocol/sdk)
  • sql.js for SQLite (same pattern I use in my tweet-scheduler MCP server)
  • Zod for config validation

If you've built an MCP server before, the architecture is familiar. If you haven't, the codebase is small enough to read in one sitting — about 800 lines of actual logic across 10 files.

The 14-Day Sequence — Where It Gets Interesting

The playbook's multi-channel orchestration is the part that's hardest to keep in your head manually. Here's the sequence the MCP enforces:

Day 1:  Email 1 (OPPS framework) + LinkedIn connect (no note)
Day 3:  If LinkedIn accepted → DM with observation + question
Day 5:  If email opened twice → CALL (hot signal!)
        If no opens → Email 2 (different pain angle)
Day 7:  Email 3 — new signal-based angle
Day 10: Call anyone who engaged on any channel. Voicemail if no answer.
Day 14: Email 4 — the breakup. "Timing isn't right. No hard feelings."

Tracking this across 30 companies, each at different points in the sequence, across three channels, with engagement signals changing daily — that's where the Google Sheet breaks down and the MCP earns its keep.

When you ask "what should I do today?", the server looks at every active prospect, checks their touchpoint history against the sequence rules, and returns a prioritized list. High-priority items first: the calls. Because as Prem says — email didn't close deals. Calls did. Email found who was interested. Calls converted them.

What a Real Session Looks Like

Me: Create a campaign. Thesis: "Mid-market lenders scrambling to meet
    new AML guidelines have compliance teams that can't keep up."
    Vertical: compliance/regtech.

Claude: Campaign created. Add your 30 target companies next.

Me: Add James Chen, Head of Compliance at Pacific Lending. Signal:
    new regulation. Observation: "New AML guidelines dropping in Q2."
    Pain language: "manually tracking regulatory changes across
    10-15 jurisdictions." Tier 1.

Claude: Added. Tier 1 — gets email + LinkedIn + calls. Sequence
        starts today.

Me: What should I do today?

Claude: 3 actions:
  [HIGH] CALL James Chen — opened Email 1 twice
  [HIGH] Send LinkedIn DM to Sarah Park — accepted connection
  [MEDIUM] Send Email 2 to David Liu — no opens on Email 1

Me: I called James. He said "bad timing, call back in 3 months."

Claude: Logged. Here's the 2-step response:
  Step 1: "What makes the timing so bad right now?"
  Step 2: "Other compliance heads find it helpful to see a quick
  demo during planning so they know if it's worth budgeting for."
  Then: "Would you be against finding 30 minutes, say tomorrow
  or Friday?"
  Then go silent. Wait.

The objection coaching is pulled directly from the playbook's table. Six objection types, each with a follow-up question and a reframe. The first objection is almost never the real one — the framework teaches you to dig before you respond.

What's NOT in the MCP (and Why)

An honest gap list:

By design (the playbook says do it manually):

  • The 5-minute research per prospect — LinkedIn, G2, company news. The research IS the learning.
  • LinkedIn connection requests and DMs. No API. Must be human.
  • Actual phone calls. Obviously.

Not yet built (v0.2 candidates):

  • Pain language library aggregated by vertical (currently per-prospect only)
  • Volume benchmarks (the playbook specifies 80 LinkedIn requests/week, 40 dials/day — not tracked yet)
  • Week 1 guided checklist
  • Email open tracking integration (currently manual)
  • CSV export for people who still want the Google Sheet

Would require external APIs:

  • G2/Capterra review scraping
  • LinkedIn signal monitoring
  • Crunchbase/BuiltWith company research

The playbook itself says "tools scale later, the process is identical." The MCP focuses on the process — the frameworks, the sequence, the tracking — not on automating the research. That feels right for an alpha.

Where You Can Use It

This is an MCP server, so it works with any client that speaks the protocol:

  • Claude Code (CLI) — my primary interface
  • Claude Desktop (app)
  • Cursor / Windsurf — both support MCP
  • Any future MCP client

Setup is: clone, pnpm install, pnpm build, add one JSON block to your client config, restart. Under 5 minutes.

The Repo

It's public: github.com/maheshcr/outbound-playbook

Tagged v0.1.0-alpha. The README has full setup instructions, a tools reference, and the coverage map against the original playbook.

What I Learned Building This

Three things stood out:

1. Playbooks are perfect MCP candidates. Any methodology that's (a) process-heavy, (b) stateful across sessions, and (c) naturally conversational is a good fit. The outbound playbook hits all three. I suspect there are dozens of practitioner playbooks out there — hiring, fundraising, customer success - that would work the same way.

2. The "brain" is simpler than you'd think. The sequence logic is about 150 lines of TypeScript. It's just: given this prospect's tier + touchpoints + day number, what should happen next? The complexity isn't in the code. It's in the domain knowledge that Prem codified in the playbook.

3. Claude doesn't need tools to write - it needs tools to remember. The OPPS email framework works fine as a system prompt. Claude doesn't need an MCP tool to draft an email. What it needs is the prospect context, the campaign state, the touchpoint history. The MCP server is a memory layer, not a generation layer. The content tools just package the right context for Claude to work with.

What's Next

I want to add the pain language library - being able to say "show me the top pain phrases for compliance buyers across all my campaigns" would be genuinely useful for refining messaging over time.

And volume benchmarks. The playbook has specific activity targets. Tracking against them turns the MCP from a campaign manager into a performance coach.

But for now, it works. Thirty companies, four channels, fourteen days, one conversation with Claude. That's the pitch.

The outbound methodology in this MCP server is from Prem Kumar / Revmaze, presented at the SaaSBoomi GTM Scars roundtable, March 2026. I built the MCP server; the playbook wisdom is his.