MCPs vs APIs in a Production Enrichment Pipeline
Alexander Shartsis walks through Skyp's twelve-MCP Claude Code setup and why the production pipeline drops to direct APIs when volume and cost matter
👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 25,000+ operators building GTM systems that compound.
Show Me Your Stack, Episode 2: Enrichment Pipelines in Claude Code
This episode: Alexander Shartsis walks through an enrichment pipeline built in Claude Code, backed by a production-grade system powering Skyp’s managed outreach. Over a dozen MCP connections. Direct API layer underneath. Stage 3 agentic workflow. The breakdown below maps the build back to the Revenue Architecture.
The Targeting Failure That Enrichment Is Supposed to Solve
Most outbound campaigns fail silently. The emails go out. The open rates look reasonable. Nothing converts. The post-mortem blames the copy, the subject line, the send time, the offer. It is rarely any of those things.
The silent killer is list quality. The people on the list are the right title at the right company. They match the ICP on paper. But they are not in market. They have no documented need. No signal. No timing indicator. The campaign was dead before the first email was drafted because the enrichment layer did not produce signal. It produced demographics.
Alexander Shartsis has spent a year building Skyp’s enrichment and outbound system. Before that, he led M&A at Opendoor, closing four acquisitions in six months for a public company doing over two billion in revenue. He has bootstrapped, raised, exited, and shut down companies. He built Skyp because the enrichment problem is not a data gap. It is an architecture gap. The tools exist. The APIs exist. The failure is in how they are composed, what order they are called in, and whether anything upstream validates the output before it reaches the send layer.
In this episode, Alex builds a basic enrichment tool live in Claude Code using plan mode and the Apollo API, then walks through the production version that runs Skyp’s managed campaigns at roughly fifty cents per lead. The gap between those two builds is the entire argument for why enrichment is architecture, not a feature.
The Live Build: Claude Code Plan Mode to Working Tool
Alex starts the build on screen. Claude Code in the terminal. Plan mode activated with Opus for planning, Sonnet for code generation. The prompt is specific: build an enrichment tool that uses web search to find signals about people and Apollo API for email and contact information. Run locally. Keep it simple.
Claude returns a plan. A Python script. Data sources, structure, output format. Alex pauses here and makes a point that most people skip: read the plan before you execute it. Claude’s plan mode is not a formality. It is the architectural review. If the plan calls the wrong APIs, structures the data incorrectly, or misses a step, fixing it after execution costs more tokens and more time than catching it in the plan.
The distinction between Claude Code’s three modes matters here. Edit-after-asking mode does not plan. It reacts to the immediate task, builds the thing in front of it, then discovers downstream dependencies. Plan mode thinks through the whole system first, breaks it into steps, then executes sequentially. For anything beyond a single-file script, plan mode produces a fundamentally different output. Alex uses it for every build.
Claude recognizes that Alex has already built a larger enrichment app in the same repo. It asks why it is building a smaller version. This is worth noting. Claude Code maintains context across the project. If you have existing code that overlaps with the new build, it will flag it. Alex redirects it to build a standalone example.
The build runs. Claude writes the Python script, wires up the Apollo API, adds web search for signal enrichment. The output is functional. A founder or operator could take this script, point it at their ICP parameters, and get enriched leads with contact information and web-sourced signals for ten to twenty cents per lead.
This is the baseline. What Alex builds next is the production layer that turns a script into a system.
The MCP Stack and When Not to Use It
Alex’s Claude Code environment has over a dozen MCP servers connected. He walks through the ones he uses most and what each one does in the workflow. But the architectural lesson is not “connect everything.” It is knowing when to use an MCP and when to drop to the API directly.
Gmail provides email history context. When building an outreach list, Claude can check Gmail to remove anyone Alex has already emailed. No manual deduplication. No CRM lookup. The MCP queries the inbox directly.
Grain is the meeting recorder. It has an MCP that lets Claude query meeting summaries and action items. The use case is follow-up prioritization: who did Alex meet with this week, what was discussed, who needs a follow-up. The data lives in Grain’s interface, but the MCP makes it queryable from the same environment where the enrichment runs.
Slack serves as the notification layer. Long-running enrichment processes send a Slack message when they finish. This is the difference between watching a terminal and doing other work while the system runs.
Intercom handles customer support content. Alex built an automation that runs every morning: it checks new GitHub commits, identifies product changes, and updates or creates Intercom help articles automatically. New features get flagged to Slack for human review before publishing. Existing feature changes publish directly.
Stripe provides the customer list. When building outreach lists, Claude pulls current customers from Stripe and removes them. No manual exclusion list. No stale CSV. The deduplication is live.
Ahrefs is the SEO and SEM data source. Competitive intelligence, keyword monitoring, website performance. This MCP is more of a data feed than an action layer.
Trigify monitors LinkedIn for signal data. It tracks people posting about specific topics and surfaces them as potential leads. The same function could be replicated with Claude web search, but Trigify packages it as a structured API.
Canva lets Claude build slides, mockups, and logos without leaving the terminal. Alex uses it for quick visual assets.
Calendar handles scheduling context. Meetings, availability, follow-up timing.
Skyp is the send layer. Once a list is enriched and validated, Claude pushes it directly to Skyp to start or add to a campaign. The full loop, from enrichment to send, runs without switching tools.
The rest are Claude’s built-in connectors (web search and others visible in the MCP list) that Alex uses but did not walk through individually.
The architectural insight is the cost tradeoff between MCPs and direct APIs. Every MCP call consumes tokens because the LLM reads the MCP documentation, constructs the request, and processes the response. A direct API call is just the raw request. For occasional tasks (checking Gmail, querying Grain), the token overhead is negligible. For high-volume operations (enriching hundreds of leads through Apollo), the overhead compounds. An hour-long enrichment run becomes two hours. Two hours becomes four.
Alex’s production system uses MCPs for convenience and context tasks. It uses direct APIs for the enrichment pipeline itself. The decision boundary is volume. If you are calling something ten times, use the MCP. If you are calling it a thousand times, use the API.
Keep reading with a 7-day free trial
Subscribe to GTM Vault to keep reading this post and get 7 days of free access to the full post archives.