Your marketing ops team just installed three Claude extensions in the same week. One pulls campaign data from HubSpot. One enforces your brand voice on every draft. One came as a bundle from a vendor who promised "AI-powered content at scale." Now something's running that nobody remembers configuring, and the token bill jumped 40%.
This is the extension-layer problem nobody warned you about. Anthropic shipped three separate ways to extend Claude in under a year: MCP arrived November 2024, plugins entered public beta October 2025, and skills followed a week later. Marketing teams moved fast on all three. Then they stopped being clear on what any of them was actually for.
The confusion has a specific cause, and it's the same pattern I've seen kill marketing technology investments for a decade: people treat these as three parallel choices for roughly the same job. They are not. Each layer solves a different problem. Conflate them and you get capability sprawl, unclear permissions, and a finance partner asking why your AI line item tripled without a corresponding lift in pipeline.
The Operating Model That Actually Holds
Here's the mental model I use when advising CMOs on Claude deployments. It maps directly to how you'd explain any marketing technology stack to your CFO: what does it do, what does it cost, and who controls it.
Connectors are the plumbing. They link Claude to external systems: your CRM, your email platform, your analytics suite. Without them, Claude can't see your actual data. With them, Claude has read and sometimes write access to the systems where your pipeline lives. The underlying protocol is MCP (Model Context Protocol), which functions like a universal adapter for AI-to-software connections.
Skills are the instructions. They teach Claude how to perform a specific task your way: your brand voice, your approval workflow, your naming conventions. A skill is a text file with YAML frontmatter and Markdown instructions. Each skill costs roughly 30 to 50 tokens when Claude scans it at session start, and the full body loads only when a task matches. That's the efficiency play: you can have dozens of skills installed without bloating every conversation.
Plugins are bundles. This is the distinction most tutorials skip. A plugin is someone else's pre-packaged combination of skills, connectors, hooks, and configurations. When you install a plugin, you're not adding a third category alongside skills and MCP; you're importing a bundle that may contain both. That's why sessions get heavier and errors get harder to trace: you don't always know what's inside the box.
The Token Math Your Finance Partner Will Want
Here's where the CFO conversation gets concrete. Skills are cheap: 30 to 50 tokens each, loaded on demand. Connectors vary, but a full MCP server setup can consume 50,000+ tokens before the conversation even starts. That's the cost of giving Claude access to an external system with all its schema, permissions, and context.
Plugins inherit the token cost of everything they contain. Install a plugin with three MCP servers and five skills, and you're paying for all of it whether you use every piece or not.
The practical implication: don't install plugins because they sound useful. Install them because you've validated that the specific capabilities inside the bundle map to a workflow you're actually running. Otherwise you're paying for optionality you'll never exercise.
Which Layer for Which Job
The decision framework is simpler than the feature set suggests.
Repeating workflow with your context baked in: skill. Your content team writes the same type of case study every quarter. The structure, the voice, the approval checklist are all predictable. That's a skill. You write the instructions once, Claude follows them every time, and the output matches your standards without improvisation.
Live access to an external system: connector (MCP). Your demand gen team needs Claude to pull last week's campaign performance from HubSpot, or your ops team needs it to read deal stages from Salesforce. That's a connector. The question that tells you if you actually need MCP: does Claude need to see or act on data that lives outside the conversation? If yes, connector. If no, you're probably overengineering.
Reuse across teams or repos: plugin. You've built a working setup with two skills, one connector, and a hook that runs on every draft. Now you want the rest of the marketing org to use the same configuration without rebuilding it from scratch. That's when you package it as a plugin. The plugin is the distribution mechanism, not the capability itself.
The Build Order That Compounds
Most people blur these layers because the language around the category is still messy. A project can feel like memory. A skill can feel like intelligence. A connector can feel like automation. That framing hides what each layer is really doing.
Start with skills. They're the lowest-cost, highest-control layer. Document the procedures your team already follows, encode them as skills, and validate that Claude's output matches your standards before you add external system access.
Add connectors only when you hit a wall. If the workflow requires data Claude can't see, add the specific connector for that system. Don't install every available MCP server because you might need them later. Each one adds token cost and permission surface area.
Evaluate plugins last. By the time you're considering a plugin, you should already know what capabilities you need. The plugin is a convenience layer for distribution, not a discovery mechanism for new features.
The Governance Question Nobody's Asking
Two of these three extension types can act inside your real systems. Connectors and plugins (which often contain connectors) have read and sometimes write access to your CRM, your email, your file storage. Skills, by contrast, only shape Claude's behavior within the conversation.
That distinction matters for your security review. When your CISO asks what Claude can access, the answer depends entirely on which connectors are installed and what permissions they carry. A skill that enforces brand voice is a different risk profile than a connector that can read every deal in Salesforce.
The practical move: audit your installed connectors quarterly. Know which systems Claude can reach, what actions it can take, and who approved that access. If you can't answer those questions, you have a governance gap that will surface at the worst possible time.
The 90-Day Pilot Plan
Week one through two: inventory your team's repeatable workflows. Identify three to five procedures that are high-frequency, predictable, and currently manual. Write skills for each.
Week three through four: validate skill output against your existing quality bar. If Claude's drafts require the same level of revision as before, the skill needs refinement.
Week five through eight: add one connector for the system where your team spends the most time context-switching. Measure whether Claude's access to that data reduces cycle time on the workflows you've already skilled.
Week nine through twelve: evaluate whether your setup is worth packaging as a plugin for broader team distribution. If yes, document the configuration and test it with a second team before rolling out.
The goal isn't to use all three layers. The goal is to use the right layer for each job, at a token cost you can defend, with permissions you can explain. That's the setup your CFO will sign.
