How to Build a Claude Code Plugin for Your Sales Team (Step-by-Step)

A Claude Code plugin can collapse your sales stack into a single workspace where one AI agent queries the CRM, calls enrichment APIs, drafts outreach, and updates pipeline records inside the same conversation.

This guide walks through the four moving parts of a Claude Code plugin, what to build first, and when a custom MCP server is worth the engineering time. Most sales teams will get most of the value from Markdown files alone.

What Claude Code does and why it matters for sales

Claude Code documentation describes an agentic coding tool that runs in your terminal, IDE, or browser. The important part for sales teams: Claude Code does things instead of just summarizing what you already know. It can read and edit files, run commands, write scripts, chain multi-step workflows, and connect to external tools through the Model Context Protocol (MCP).

For a sales team, that means an agent that can pull account data from HubSpot, run an enrichment query, draft a follow-up email, and update the deal stage, all without a rep switching tabs.

You may not need to build a server from scratch to make this work. You might just need to register a few existing MCP servers and write some Markdown files.

The four moving parts of a Claude Code plugin

A Claude Code plugin has four moving parts. Mix and match based on what your team actually needs.

CLAUDE.md is persistent session memory. Store your ICP definition, objection library, competitive positioning, and sales methodology here. Claude reads it automatically on every session.

Custom slash commands are simple Markdown files. The filename becomes the command name: /prospect-research, /call-prep, /deal-review. No code required. Commit the folder to your repo and every team member gets the same commands on git pull.

Hooks are user-defined handlers (shell commands, HTTP endpoints, or LLM prompts) that run automatically at lifecycle events. They give you a way to add review gates, audit logs, and notifications around sensitive CRM actions. For example, you can block writes to the production CRM without manager review (PreToolUse), log every CRM update to an audit trail (PostToolUse), or send a Slack notification when a batch research run completes (Stop).

Here's the pattern for a PreToolUse hook that prevents reps from overwriting closed-won deal stages without sign-off:

{
"hooks": {
"PreToolUse": ["./scripts/require-approval-for-stage-change.sh"]
}
}

MCP servers connect Claude Code to your actual sales stack. Register a server once, and Claude can query your CRM, enrich contacts, and update pipeline records within a single conversation.

Step 1: Start with slash commands

Most sales teams should start here. Slash commands require nothing but Markdown files and deliver immediate value.

Create this folder structure:

your-sales-project/

├── .claude/

│ ├── commands/

│ │ ├── prospect-research.md

│ │ ├── call-prep.md

│ │ └── deal-review.md

│ └── settings.json ← hooks configuration

├── .mcp.json ← MCP server declarations (commit to git)

├── CLAUDE.md ← ICP definition, sales context

└── dist/ ← compiled MCP server

Here's a practical call-prep command (.claude/commands/call-prep.md):

allowed-tools: mcp__sales-server__get_account_health, Read

description: Generate pre-call brief for an account

model: claude-opus-4-7

Pull health data for account $1 and generate a structured call prep brief including:

- Account background and current status

- Recent activity and engagement signals

- Known pain points from previous conversations

- Likely objections and recommended responses

- Suggested talk track for this stage of the deal

Reps type /call-prep account-123 and get a structured brief. Arguments use $1, $2 for positional values or $ARGUMENTS to capture everything passed at invocation.

Step 2: Set up CLAUDE.md with sales context

This is where Claude gets more useful. It draws on shared organizational knowledge instead of starting fresh on every task.

Your CLAUDE.md should capture the few things reps need on every workflow: ICP definition, objection handling, competitive positioning, and stage definitions. Here's what a real one looks like for an outbound team targeting mid-market SaaS:

# Sales Context

## ICP Definition

- Target: B2B SaaS companies, 50-500 employees, Series A-C

- ACV range: $20K-$100K

- Must use HubSpot or Salesforce as primary CRM

- Bonus signals: VP of Sales hired in last 90 days, recent funding round, job posts for SDRs

## Objection Library

**"We already use [competitor X]"**

Response: Acknowledge their investment. Ask what's working and what's not. Position around the integration gap, not a full rip-and-replace.

**"We're not ready to buy this quarter"**

Response: Agree on timing. Shift to a technical evaluation now so they're not starting from zero next quarter. Offer a sandbox.

## Deal Stage Definitions

- Stage 1 (Discovery): First meeting completed, pain confirmed

- Stage 2 (Evaluation): Technical stakeholder engaged, demo delivered

- Stage 3 (Negotiation): Proposal sent, procurement involved

- Stage 4 (Closed Won): Contract signed, handoff to CS

Put this at your project root. Claude reads it automatically. Every rep who joins the team inherits that context on day one. We define ICPs and targeting foundations before outbound touches a prospect, so this file becomes a single source of truth that the entire team can version-control.

Step 3: Register existing MCP servers for your sales stack

Most teams overcomplicate this step. Before building anything custom, register the connectors that already exist.

For HubSpot, a native MCP server is available at https://mcp.hubspot.com. Refer to HubSpot's documentation for the current registration command, since the syntax may change between Claude Code releases.

For Salesforce, the official npm package can be registered via your project configuration:

{

"mcpServers": {

"salesforce": {

"command": "npx",

"args": [

"-y", "@salesforce/mcp",

"--orgs", "my-crm-org",

"--toolsets", "data,metadata,users"

]

}

}

}

Some community guides describe a project-scoped MCP configuration using a .mcp.json file in your project directory. The official Model Context Protocol and Claude Code documents do not currently specify this as the standard configuration file location, so verify the path that matches your installed version. Once configured, commit the file to git so every rep who pulls the repo gets the same CRM connections.

Verify everything registered:

claude mcp list

Step 4: Build a custom MCP server when you need one

This step requires a developer. The work itself is not massive.

Prerequisites: Python 3.10+ for the Python path, or Node.js for the TypeScript path. Claude Code installed locally.

Initialize the project:

mkdir my-sales-mcp-server && cd my-sales-mcp-server

npm init -y

npm install @modelcontextprotocol/sdk zod@3

npm install -D @types/node typescript

mkdir src && touch src/index.ts

Add the necessary package.json fields for your project's module system and build/start commands:

{

"type": "module",

"scripts": { "build": "tsc", "start": "node dist/index.js" }

}

Write the server logic:

#!/usr/bin/env node

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';

const server = new McpServer({

name: 'sales-crm-server',

version: '1.0.0',

});

server.tool(

'get_account_health',

'Get health score and activity for an account',

{ accountId: { type: 'string', description: 'Account ID from CRM' } },

async ({ accountId }) => {

const response = await fetch(

`${process.env.CRM_API_URL}/accounts/${accountId}/health`,

{ headers: { Authorization: `Bearer ${process.env.CRM_API_KEY}` } }

);

const data = await response.json();

return { content: [{ type: 'text', text: JSON.stringify(data) }] };

}

);

const transport = new StdioServerTransport();

server.connect(transport);

Build it (npm run build), then register:

claude mcp add --scope project my-sales-server -- node ./dist/index.js

Step 5: Test before your team touches it

You have two reasonable options.

The MCP Inspector is the official tool for testing servers in isolation:

npx @modelcontextprotocol/inspector node path/to/server/index.js

You can also test directly inside a Claude Code session by running /mcp. That command lists all connected servers and their available tools. A few common failures and the fixes that usually clear them:

• A 401 error usually means an expired access token
• "Connection refused" usually means the server path is wrong, so use absolute paths
• "Tool execution failed" usually points to a missing environment variable

Check the token first before you burn an hour debugging.

Step 6: Deploy for the team

Deployment is straightforward. Commit .mcp.json and .claude/commands/ to your repo. Have each developer set their own CRM_API_KEY environment variable locally. The server config and slash commands are shared through the repo so the whole team stays in sync.

For batch automation without a human in the loop, you can run Claude Code from the command line with a prompt:

cat accounts.csv | claude -p "Score each account against our ICP definition and output a ranked CSV"

Where Claude Code plugins pay off for sales teams

The value shows up fast once the commands and connectors are live.

ICP-scored account research at scale

Feed a list of target domains. Claude pulls firmographic data, checks recent funding, identifies the tech stack, and scores against your ICP criteria. Output: a ranked account list with research summaries. Scoring against real signals before any outreach changes which accounts get rep attention.

Full outbound loop in one workspace

With the right connectors active, the sequence runs in one workspace: search, enrich, create the contact, add to a sequence. No tab juggling.

Post-call transcript to CRM update

Feed a call recording transcript. Claude can extract objections, sync conversation data to your CRM, and draft a follow-up email based on the specific objections raised. Over time, your objection library grows from real call data rather than guesswork.

Tiered outbound with ICP-score gating

Split prospects by fit score. High-fit accounts get full research briefs and personalized outreach. Mid-tier routes to automated sequences. Low-tier goes to nurture. This tiered approach mirrors how we structure campaigns at Understory, where paid media warms the high-fit tier while outbound handles the rest.

The goal is tighter execution with less rep friction.

What Claude Code plugins actually cost

Claude Code access is included with eligible Anthropic plans, including Claude Free, Pro, Max, Team, and Enterprise for OAuth-authenticated use. MCP servers can be open-source and free. The real cost is developer time to wire the initial connections and write your slash commands.

After that, reps run commands without touching code. If you already pay for your CRM and enrichment stack, you're adding setup time to collapse multiple browser tabs into one workspace.

Coordinate paid media, outbound, and RevOps with Understory

A Claude Code plugin scales a sales playbook. Its value depends on the ICP definition, outbound sequences, paid media positioning, and CRM architecture underneath it.

That's where Understory starts. We run paid media management, Clay-powered outbound services, and HubSpot-native RevOps as a single coordinated system for B2B SaaS teams. One team, one ICP, every channel feeding the same pipeline. RemoFirst replaced their entire internal SDR team to work exclusively with us once that system was in place.

If you're spending more time coordinating vendors than optimizing campaigns, schedule a consultation to see how Understory eliminates the overhead of managing separate paid, outbound, and ops vendors.

FAQ

Do we need a developer to do this?

Not for slash commands or CLAUDE.md. You do for a custom MCP server.

What should we build first?

Start with slash commands and shared sales context in CLAUDE.md. Register existing MCP servers before you build anything custom.

What actually makes this useful for sales?

Shared context, reusable workflows, and direct connections to your CRM and enrichment tools. The win is less tab switching and more consistent execution.

When should we build a custom server?

When the existing connectors do not cover the workflows your reps actually need.

What does the team deployment look like?

Commit the configuration files to the repo, then have each developer set local environment variables like CRM_API_KEY. That keeps the setup shared and the credentials local.