How to Think With MCP
Outcome: you can take a GTM job you currently do by hand and express it as a tool chain your AI runs in one pass — and you know which jobs to leave in a table instead.
- Surface
- MCP server
- Level
- Intermediate
- Uses
- check_credits — the rest is the model
- Credits
- 0 to follow, ~5 to try the worked example
- Prerequisite
- MCP server connected to your AI client
Not connected yet? MCP server setup takes about two minutes and needs no API key.
The mental model
The Sync GTM MCP server hands your AI client roughly 50 data tools — people search, company search, waterfall email enrichment, verification, LinkedIn activity, hiring and funding signals, tech stack, traffic, ads.
Once they are attached, your AI is a GTM operator that can act, not a chatbot that can advise. So stop writing questions and start writing work orders.
| Old habit | MCP habit |
|---|---|
| ”Who are good prospects for us?" | "Find 25 people matching these filters, then enrich their work emails” |
| Ask for advice, do the work yourself | Describe the outcome and the bounds, let the chain run |
| One answer per message | One chain per message, with a table at the end |
The unit of work is no longer a question. It is a chain: source → filter → enrich → verify → act.
This is the same four-stage framework the rest of the course builds in a table — Find, Research, Enrich, Outreach. MCP does not change the framework. It changes who assembles the steps: you drag columns in the app, you describe the chain in MCP.
Think in chains, not questions
Every useful MCP run is three moves in sequence, and the order is always the same.
Source the rows
One search tool produces the list — find_people, find_companies, linkedin_post_commenters, search_linkedin_job_openings. Cheap per row, and it decides everything downstream. A bad list cannot be rescued by good enrichment.
Cut the rows
Filtering is free. It happens in the model’s context on data you already paid for — titles, headcount, country, whether they commented or only reacted. Every row you cut here is a row you do not pay to enrich.
Spend on the survivors
find_work_email at 1 credit, verify_email at 0.3, enrich_person at 1. These are the expensive steps and they run last, on the shortest possible list.
Chains that cost too much are almost always chains where step 3 ran before step 2.
Why MCP is faster
The comparison that matters is not MCP against the app. It is MCP against what you do today — a search tab, an enrichment tab, a spreadsheet, and a copy-paste between each.
| Manual | MCP | |
|---|---|---|
| Tools open | 4–6 tabs | One chat window |
| Handoffs between steps | Copy-paste per step | None — output feeds the next call |
| Time for 25 warm leads, enriched and verified | 45–90 minutes | 2–4 minutes |
| Where the result lands | A spreadsheet you clean up | A table or CSV in the shape you asked for |
| Repeating it next week | Do it all again | Re-run the same prompt |
The speed comes from one place: the output of every tool is already in the format the next tool takes as input. A LinkedIn URL from a search result goes straight into an email lookup; the email goes straight into verification. Nothing gets exported, reformatted or re-typed, and that plumbing is most of what makes the manual version slow.
Why it is also cheaper
Faster is the obvious win. Cheaper is the one people miss, and it comes from three things.
- Filtering is free and it happens mid-chain. In a manual flow you enrich first and qualify after, because qualifying is the tedious part. In a chain the model qualifies before it spends, so you pay for 25 rows instead of 200.
- You only pay for what you asked for. No seat licence, no minimum credit pack per tool, no data subscription sitting idle between campaigns. A chain that touches 25 people costs the credits those 25 lookups cost.
- Failures cost nothing downstream. An empty email result stops that row, and the verification step never fires on it. In a manual flow you have usually already paid for the whole batch.
The same property makes a sloppy prompt expensive. “Enrich everyone in this list” against 400 rows is a chain the model will run enthusiastically and completely. Always state the cap — “the first 25” — and ask for a credit report at the end.
Phrase a run so the right tool fires
Four rules cover almost every failed run. The full version, with vague-versus-strict examples you can copy, is the Prompting guide — read it once before your first real chain.
Name the tool
Say find_people, not “search LinkedIn”. Several tools look alike to a model and the wrong pick still costs credits.
Spell out every filter
Titles, seniority, headcount, country, industry — and the exclusions too. If you did not say it, it was not applied.
Cap the run
“Return 25.” Search tools page, and pages cost. An uncapped chain is the single most common source of an unexpected bill.
Ask for raw rows
“Return a table: name, title, company, LinkedIn, email, verification status.” Left to itself a model summarizes, and you lose the columns you just paid for.
A worked example
The job: 25 warm prospects from a competitor’s LinkedIn post, enriched and verified.
As a question — vague tool, no cap, no filter, summarized output:
Find me sales leaders engaging with competitor content and get their emails.As a chain — named tools, filters, a cap, raw output:
Use the Sync GTM MCP server.
1. Get the commenters on this LinkedIn post: <post_url>
2. Keep only Head of Sales, VP Sales, CRO and RevOps titles at companies
with 51-500 employees. Drop everyone else before spending anything.
3. For the first 25 survivors, find their work email. Do not guess email
patterns — skip anyone with no result.
4. Verify each email found and drop anything undeliverable.
Return a table: name, title, company, LinkedIn URL, email, status.
Report credits used at the end.Roughly 0.3 credits for the commenters, nothing for the filter, then about 1.3 credits per survivor. Around 33 credits for 25 verified contacts, in a single message.
The second version is not longer because it is more polite. It is longer because every line removes a decision the model would otherwise have made for you — and each of those decisions had a price.
When a table still beats a prompt
MCP is not a replacement for the app. It trades repeatability for immediacy.
| Use MCP when | Use a table when |
|---|---|
| The job is one-off, or the shape changes each time | The same job runs weekly on a new list |
| You want the answer inside the conversation you are already having | You need columns, history and re-runs |
| Volume is tens of rows | Volume is hundreds or thousands |
| You are exploring and will change your mind mid-run | The workflow is settled and should be scheduled |
The honest rule: prompt it until it works, then move it to a table if you will run it again. Most of this course’s later lessons are the table version of a chain that started as a prompt.
Check your work
Take one job you did by hand this week and write it as a chain. Then check:
- Does every step name a tool, or are some steps still a wish?
- Is the free filtering step above the paid enrichment step?
- Is there a number in the prompt capping the run?
- Would you notice if a step silently returned nothing?
If the last one is a no, add “report how many rows each step returned” to the prompt. A chain that quietly drops rows looks identical to one that worked.
Where this breaks
If an answer arrives instantly and no credits are charged, no tool ran — the model answered from training data, and profile or company details will be confidently out of date. Re-prompt with the tool name and “use the Sync GTM MCP server”. More fixes in Common issues.
Long chains drift. Six steps in one message is fine; twelve is where a model starts skipping the filter or re-running a search it already ran. Split anything that long into two messages and check the row count between them.
Further automation
Once a chain works, stop retyping it. A GTM agent is that chain saved as a skill file — already scoped to the right tools, filters and caps — that you trigger with a slash command.
- Lead List Builder — an ICP description in, a filtered and enriched list out
- Contact Finder — a company list in, verified decision-maker contacts out
- Account Researcher — one company in, a full signal brief out
- Attio / HubSpot / Salesforce Enricher — CRM records in, filled fields back
Check the library before writing your own chain from scratch — most of what this course builds already exists there as a one-command version.
Next lesson
05 — From prompt to reusable GTM agent, turning a chain that works into a skill file your whole team can trigger.
The three build modules at the end of this course — agentic outbound, the account researcher and CRM auto-enrichment — are all chains. Everything here is the thinking behind them.
Reference for this lesson: Prompting guide, Tools, MCP server setup, What you can do.