Claude Skills vs MCP vs traditional tools for GTM stacks

Three primitives now define the AI surface area of a revenue stack. Claude Skills, MCP servers, and traditional tool integrations. They look adjacent on a feature list. They solve different problems, and teams that conflate them ship the wrong thing.

This post covers what each primitive is, the decision tree we use on real builds, and a worked example of how the three combine into one outbound pipeline. The framing comes from the TVA methodology we use across GTM subagent engagements.

The three primitives, defined

A Claude Skill is a folder of files Claude reads to do a specific kind of work. A SKILL.md tells the model when to use the skill and how to think about the task. Supporting files give it templates, examples, and procedures. Skills travel with the repo. They activate when Claude sees a relevant request. They do not connect to systems by themselves.

An MCP server is a process that exposes tools, resources, and prompts to an agent through a standard protocol. The agent calls the server when it needs to read or write to a system. Hubspot has an MCP server. Salesforce has one. Slack has one. So does Postgres. The agent decides when to call. The server decides what's available.

A traditional tool integration is the code your engineering team has written for ten years. A Python job that hits the Salesforce REST API on a cron. A webhook that posts to Slack. A Snowflake task that runs SQL. No model involvement. No reasoning loop. It runs, it logs, it succeeds or fails.

What each is good at

Skills carry procedure. They encode the playbook for repeatable work: how to run an ICP refresh, how to draft a TVA-grade outbound message, how to score a pipeline review, how to triage an inbound lead. If your team has a Notion doc titled "How we do X," the doc wants to be a Skill.

MCP servers carry capability. They expose verbs the agent can use during a task: search the CRM, update a lead score, post to a channel, query the warehouse. If your agent needs to know something that lives outside its context, the connection wants to be an MCP server.

Traditional integrations carry volume. They handle the boring, high-frequency, no-judgment work that should never wake a model up. Nightly enrichment of new leads. Hourly sync between Salesforce and the warehouse. Webhook routing on form submits. If a model doesn't add value, don't pay for tokens.

The decision tree we use

For every piece of revenue work, we ask three questions in order.

First, does this work require judgment or reasoning that benefits from a model? If no, build a traditional integration. We don't pay Claude to copy fields. Most of the "AI everywhere" rebuilds we see fail this test in the first month.

Second, if a model is involved, does the task have a stable procedure the team repeats? If yes, write a Skill. The procedure becomes the SKILL.md. The team's voice and constraints live in CLAUDE.md. The agent reads both and stays in the lines. This is where most of our value gets delivered, and where teams underinvest.

Third, during execution, does the task need data or actions the agent can't reach from context? If yes, the task needs an MCP server. The Skill calls the server. The server returns data or makes a change. The pair is composable, testable, and survives team changes.

A worked example: outbound with the three primitives

A simple TVA-grade outbound run uses all three.

The traditional integration is a nightly job that pulls new accounts from Salesforce, hits Verum and Provyx for enrichment, and writes a clean accounts table to the warehouse. No model. No agent. Just code that has run for a year. It feeds everything else.

The MCP server exposes the warehouse and the CRM to the agent. The agent can query accounts, read closed-won DNA, write a lead score back to Salesforce, and post a status note to the rep's Slack DM. The server lives in the team's repo. The connection is read-only by default, write-capable for specific fields, and audit-logged.

The Skill is the playbook. A `tva-outbound` skill that tells Claude what a good signal is, when to score, how to draft, what to gate, and when to escalate to a human. The Skill calls the MCP server when it needs CRM data. The Skill obeys CLAUDE.md for voice and ICP. The Skill self-scores against the TVA rubric.

None of the three could ship the outcome alone. The traditional integration is too dumb to draft. The MCP server is too low-level to know the playbook. The Skill is too disconnected to act on real data. Stacked, they form the unit we deploy for AI SDR replacement.

Where teams pick the wrong primitive

The most common mistake is shipping a workflow as an MCP server when it should have been a Skill. We see teams writing custom MCP servers that wrap a prompt with no underlying system access. That's a Skill wearing the wrong hat. It deploys harder, fits worse in the repo, and dies when the engineer who wrote it leaves.

The second most common mistake is shipping a procedure as a traditional integration when it should have been a Skill. The team writes a Python script that calls Claude through the API, parses the response, posts to Slack, and logs to S3. Three months later, the script is brittle, the prompts are scattered, and nobody can change the procedure without reading 400 lines of code. A Skill would have been one folder, three files, and editable by anyone on the team.

The third mistake is the inverse. Teams turn every batch job into an agent loop and pay for tokens on work that shouldn't have involved a model. Enrichment, deduplication, and field normalization are deterministic problems with deterministic solutions. Letting an agent reason through 50,000 rows costs more than the engineer salary it was supposed to save.

How to stage the build

For most revenue teams starting from zero, we recommend a sequenced rollout.

Week one. Identify the three repeatable AI-worthy workflows the team runs. Inbound triage, outbound drafting, pipeline review. Write one Skill per workflow. Wire it to read static CSVs from the repo. Ship internally, iterate on the prompts, prove the procedure works.

Week two through four. Promote one Skill to live data. Add a minimal MCP server that exposes the CRM. The Skill now reads real accounts and writes real scores. The procedure is unchanged. The connection point is new. The deploy is small.

Month two through three. Identify the highest-volume non-judgment work the team is doing. Convert it to traditional integrations that feed the warehouse and tee up the Skills. The integration runs nightly. The Skills run on demand. The MCP server bridges them.

By month three, the team has a clean three-layer stack. Procedures in Skills. Connections through MCP. Volume in batch jobs. Each layer is testable, replaceable, and ownable by a different role.

Why the three-layer model holds

The reason this separation matters is rate of change. Procedures change weekly as the team learns. Connections change quarterly as systems evolve. Volume jobs change yearly as scale demands. If you build the procedure into the volume job, every prompt tweak triggers a deployment. If you build the connection into the procedure, every CRM schema change breaks the playbook. The three-layer model isolates change.

The second reason is ownership. A Skill belongs to the team running the workflow. A RevOps lead can edit a SKILL.md without filing a ticket. An MCP server belongs to whoever owns the system it connects to. The CRM admin owns the CRM MCP. The data team owns the warehouse MCP. Traditional integrations belong to engineering. When the three roles overlap inside one Python script, every change becomes a cross-team negotiation. When the roles map to clean primitives, the team ships faster.

The third reason is testability. A Skill can be tested with prompt evals on real cases. An MCP server can be tested with the standard MCP harness against fixture data. A traditional integration can be tested with the same unit tests engineering already writes. Pile them into one job and your only test is "did the email send." That's not a test; that's a wish. Keeping the primitives clean keeps the test surface clean, which keeps the team confident on every change.

Skills, MCP, and traditional integrations are not competing technologies. They're roles in a system. Pick the right one for each piece of work and the build stays maintainable. Pick the wrong one and you'll rebuild it inside a year.

For the working pattern in a real repo, see Claude Code for GTM teams and how to write a CLAUDE.md for your revenue team. For the outbound pipeline that ties them together, see the outbound data pipeline we ship in Claude Code. We deploy this stack as a fixed-fee engagement and hand off the repo on day one.