MCP and API enrichment pipeline

Built from the system Alexander Shartsis, co-founder and CEO at Skyp, described on GTM Vault SMYS 2 (https://pro.gtmvault.co/episodes/smys-02). Published free by GTM Vault. Numbers below are the operator's own, from the episode; your results will differ.

When to use this

Use this when a team wants to run enrichment from Claude Code or a similar agent environment and needs to decide which systems to connect over MCP and which to call through a direct API. It also fits when outbound lists keep including current customers or people already in conversation, or when the enrichment bill is out of proportion to the list size. The output is a pipeline spec the team can build from in one sitting.

The system on the record

Alex starts from a diagnosis: campaigns fail on targeting before they fail on copy. In his words, "the silent killer is basically choosing the wrong people to reach out to" (SMYS 2, 2:19). The right title at the right company is not enough if the person is not in market.

His build has two layers.

1. Plan first. He runs Claude Code in plan mode, with the strongest model planning and a smaller model writing the code, and reads the plan before approving it, because fixing a wrong build costs more tokens and time than correcting the plan (SMYS 2, 1:07 and 5:42).
2. Connect context over MCP. His Claude Code environment holds a list of MCP servers he walks through one by one (SMYS 2, 8:46 to 17:38). Gmail removes anyone he has already emailed (SMYS 2, 9:54). Stripe pulls the live customer list so customers come off the prospect list (SMYS 2, 17:38). Grain answers who he met and still needs to follow up with (SMYS 2, 14:32). Slack posts a notification when a long run finishes (SMYS 2, 14:32). Trigify surfaces people posting about a topic on LinkedIn (SMYS 2, 17:38). Ahrefs, Canva, Calendar and Intercom cover search data, visuals, meetings and support content (SMYS 2, 16:29). The Skyp MCP takes the finished list and starts or extends a campaign (SMYS 2, 18:46).
3. Drop to the API for volume. He uses MCPs for occasional, convenience or long-running tasks and direct APIs at scale, because every MCP call spends tokens re-reading how the API works, while "the API is just the raw request" (SMYS 2, 11:03 and 12:10). He calls Apollo through its API for exactly this reason, while noting Apollo likely has an MCP (SMYS 2, 11:03). The cost is more setup time up front (SMYS 2, 12:10).
4. Supervise the output. The production version is agentic: a supervisor agent judges companies, people and signals, throws out results that do not fit and sends the worker agent back (SMYS 2, 24:24). It also knows the strengths of each enrichment API and calls only the one that fills the missing field, for example an email when the name and title are already known (SMYS 2, 25:30).
5. Run in the background. Because enrichment is a long-running process, he kicks it off over MCP and gets a Slack notification when it is done (SMYS 2, 19:54).

The result

1. Skyp delivers enrichment as a managed service at around 50 cents a lead (SMYS 2, 22:10).
2. He estimates a simple self-built tool can produce leads for 10 to 20 cents per lead (SMYS 2, 22:10).
3. Asked for the cost before the tool, he estimates it was probably 30 cents, without counting human time (SMYS 2, 23:18).
4. On scale: adding seconds per call can turn an hour into two hours, or two hours into four (SMYS 2, 13:23).
5. A Skyp customer goes live in two weeks, the time it takes to warm up email and set up the first campaign (SMYS 2, 30:51).

Run it on your company

1. Ask once, in one message, for: the ICP (company type, size, titles) and the signals that indicate someone is in market; expected list volume per run and per month; the systems that hold "who we already know" (inbox, CRM, billing, meeting recorder, support tool); the enrichment providers they pay for and which have APIs; where the list goes after enrichment (sequencer or send tool); and where the team wants alerts.
2. Build the source inventory as a table with columns: System, What it knows, Job in pipeline (exclude, context, signal, enrich, send, alert), Calls per run, Connection (MCP or API), Reason. Fill one row per system the user named.
3. Apply the volume boundary to the Connection column. Mark MCP for anything called a handful of times per run or used conversationally (inbox lookups, follow-up questions, alerts). Mark API for anything called once per lead or per company at the user's stated volume. Where a provider offers both, choose API for per-lead calls and record the setup cost in the Reason column.
4. Write the exclusion set. List every "already known" check as a rule: current customers from billing, anyone emailed in the last N days from the inbox, open deals from the CRM, competitors or companies owned by a competitor. Alex removes these from the list after search and before send. Recommend running the cheap checks (domain lists from billing and CRM) before any paid enrichment call as well, and label that as an adaptation, not his stated order.
5. Write the enrichment waterfall: for each field (company fit, person fit, signal, email, LinkedIn URL), name the provider to call first, the fallback, and the condition for skipping it because the field already exists. Mirror the supervisor rule: never call a provider for a field already filled.
6. Write the supervisor agent prompt with three checkpoints: companies, then people, then signals. At each checkpoint it states the fit test from the ICP, rejects rows that fail, and sends the worker back for replacements up to a retry cap the user sets.
7. Add a cost guard: a per-run spend ceiling, a maximum number of model calls, and a Slack or email alert on finish and on breach.
8. Write the plan-mode build prompt the user pastes into Claude Code, containing the table, rules, waterfall and supervisor prompt, with an instruction to return a plan for review before writing code.
9. Deliver one Markdown document with four sections: Source inventory table, Exclusion rules, Enrichment waterfall, Supervisor and build prompts. End with an estimated cost per lead calculated from the user's provider prices, shown with its arithmetic.

Tools on the record

1. Claude Code: orchestration environment in plan mode.
2. Cursor: runs Claude Code with parallel agents.
3. Apollo: contact data and email enrichment via API.
4. Gmail: inbox history over MCP, used to drop anyone already emailed.
5. Stripe: customer list retrieval and dedupe over MCP.
6. Grain: meeting recordings queried for context.
7. Slack: notification and alerting layer over MCP.
8. Trigify: LinkedIn signal monitoring.
9. Ahrefs: competitive and SEM intelligence.
10. Intercom: support content as auto-documentation.
11. Canva: slides, mockups and logos.

Any tool doing the same job works; the method is the point. Full stack: https://pro.gtmvault.co/stack/operator/alexander-shartsis

Where it breaks

1. Unwatched agent loops get expensive. Alex describes an agentic process calling Opus repeatedly overnight and costing $482 before the account paused (SMYS 2, 29:42 and 30:51). Set the spend ceiling in step 7 before the first run.
2. Order and vendor choice decide the cost. He cites a company quoted $800 to enrich 500 people in Clay, where he expected not more than a dollar per lead (SMYS 2, 28:55 and 29:42). Audit the waterfall before scaling it.
3. MCP at volume. Running per-lead calls through an MCP adds token overhead to every call and stretches long runs (SMYS 2, 12:10 and 13:23).
4. Heavy CRM stacks. He argues a fully built Salesforce or HubSpot is less MCP friendly and may need a GTM engineer to wrangle (SMYS 2, 26:42 and 27:47).
5. Building before knowing the problem. His recommendation is to work with a vendor for a quarter first and build your own once you understand what works (SMYS 2, 29:42).