---
title: "FirstSales MCP in Claude Code: 5 Minute Setup Guide"
description: "Connect FirstSales MCP to Claude Code in five minutes. Real commands, OAuth sign-in, a read-only smoke test and safety rules."
date: "2026-08-31"
tags: "mcp, claude-code, firstsales-cli, outbound, ai-agents"
readTime: "25 min read"
author: "FirstSales Team"
slug: "firstsales-mcp-claude-code-setup"
canonical: "https://firstsales.io/blog/firstsales-mcp-claude-code-setup/"
---

# FirstSales MCP in Claude Code: 5 Minute Setup Guide

**TL;DR:** Install the CLI, add the `firstsales-product` server with one `claude mcp add --transport http` command, sign in through OAuth, then read your tool list before you trust it. The connection takes five minutes. The habit that keeps it safe is a three-prompt, read-only smoke test run before any edit.

---

## Table of contents

- [What connecting FirstSales to Claude Code gives you](#what-connecting-firstsales-to-claude-code-gives-you)
- [Before you start](#before-you-start)
- [Step 1: install the CLI and prove who you are](#step-1-install-the-cli-and-prove-who-you-are)
- [Step 2: add the server](#step-2-add-the-server)
- [Step 3: sign in with OAuth](#step-3-sign-in-with-oauth)
- [Step 4: read the tool list your grant received](#step-4-read-the-tool-list-your-grant-received)
- [Step 5: run the three-prompt smoke test](#step-5-run-the-three-prompt-smoke-test)
- [Pick the right scope](#pick-the-right-scope)
- [What MCP does and what the CLI does](#what-mcp-does-and-what-the-cli-does)
- [Permissions inside Claude Code](#permissions-inside-claude-code)
- [Troubleshooting a failed connection](#troubleshooting-a-failed-connection)
- [A first-week routine](#a-first-week-routine)
- [When the tool list changes](#when-the-tool-list-changes)
- [FAQs](#faqs)
- [Conclusion](#conclusion)

## What connecting FirstSales to Claude Code gives you

Most setup guides stop when the green "Connected" label appears. That label only proves a socket opened. It says nothing about which tools your account received, what they can change, or whether the model will pick the right one when you ask a vague question.

This guide takes a different position: treat the connection as a permission review, not a plug-in. You will finish the five steps in about five minutes, and you will also know exactly which doors you opened.

FirstSales is an AI SDR and cold email product. Its Product MCP server lets an MCP-aware client such as Claude Code read and edit campaign context in plain language. The server is named `firstsales-product`, uses the streamable HTTP transport, and lives at `https://api.app.firstsales.io/mcp`, according to the `mcp.json` that ships inside the `@firstsales.io/cli` package.

If the protocol itself is new to you, start with [what MCP is for sales teams](/blog/what-is-mcp-for-sales). It covers the vocabulary in about ten minutes of reading.

The [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-11-25) defines MCP as an open protocol that connects LLM applications to external data sources and tools. Anthropic documents the Claude Code side in its [MCP guide](https://code.claude.com/docs/en/mcp).

> "Tools represent arbitrary code execution and must be treated with appropriate caution." (Model Context Protocol specification, 2025-11-25 revision)

That sentence from the specification sets the tone for everything below. A tool that edits a campaign is code that runs on your behalf, so you review it before you let it run.

As of October 2026, the CLI package is `@firstsales.io/cli` version 0.1.11. The commands in this post come from its README and bundled skills, and nothing here was run against a live account while writing.

## Before you start

You need four things. Check them first, because a missing one produces confusing errors later.

1. Claude Code installed and signed in on your machine.
2. Node 20 or newer, because the CLI README lists `node >= 20`.
3. A FirstSales account with at least one workspace.
4. A browser on the same machine, because the MCP sign-in opens an OAuth page.

You also need to know your organization and workspace identifiers. The CLI prints them in step 1, so do not hunt through the app for them.

Keep one rule in mind from the first minute. Never paste an API key into a prompt, a chat message, a commit or a blog comment. Keys belong in environment variables, and the MCP server does not use them at all.

That second fact surprises people. The `firstsales-product-mcp` skill states that Developer API keys and dashboard cookies are not accepted by Product MCP. MCP signs you in with OAuth and PKCE instead, while the CLI uses a Developer API key.

So you will end up with two separate credentials, each for a different surface. Knowing which one you are holding at any moment prevents most setup mistakes.

## Step 1: install the CLI and prove who you are

You can add the MCP server without the CLI. This guide installs the CLI first for one reason: it gives you a second, independent view of your account that you can compare against what the model tells you later.

```bash
npm i -g @firstsales.io/cli
firstsales --help
```

Next, create a Developer API key in the FirstSales app with the narrowest access you need. For a read-only first day, that means read scopes only. The README example for `api-keys create` uses scopes such as `campaigns:read` and `contacts:write`, and the same page says raw keys are shown once and cannot be retrieved later.

Export the key as an environment variable so it never lands in a file you might commit.

```bash
export FIRSTSALES_API_KEY="<YOUR_FIRSTSALES_API_KEY>"
export FIRSTSALES_BASE_URL="https://api.app.firstsales.io"
```

Now verify the identity the key resolves to.

```bash
firstsales whoami --json
firstsales doctor --pretty
```

`whoami` is the FirstSales equivalent of `npm whoami`. The README says it validates the active token and prints the user, key, organization and workspace context without exposing the raw or hashed key.

`doctor` checks your setup. According to the command reference it calls the same `GET /api/v1/whoami` route, so a clean `doctor` and a clean `whoami` tell you the same thing in two formats.

Then list what you can reach.

```bash
firstsales orgs list --json
firstsales workspaces list --org org_123 --json
firstsales campaigns list --org org_123 --workspace ws_123 --json
```

Replace `org_123` and `ws_123` with the identifiers from your own output. Save the campaign list somewhere, even as a text file in a scratch folder. It is your ground truth for the smoke test in step 5.

The README summarizes the agent loop in one line that is worth memorizing: "Inspect first. Mutate deliberately. Verify after every action." Every step in this guide follows it.

## Step 2: add the server

Claude Code adds remote servers with one command. The [Claude Code MCP documentation](https://code.claude.com/docs/en/mcp) gives the basic syntax as `claude mcp add --transport http <name> <url>` and calls HTTP the recommended option for remote servers.

For FirstSales the command is:

```bash
claude mcp add --transport http firstsales-product https://api.app.firstsales.io/mcp
```

The name `firstsales-product` matches the server name in the package's `mcp.json`. Keeping the same name makes your setup easy to compare with the official file and easy to explain to a teammate.

The command prints an "Added" line when the configuration is written. That line means a config entry exists. It does not mean you are signed in.

Check the status from your terminal.

```bash
claude mcp list
```

Anthropic's documentation says this command shows a health label next to each server, such as connected, needs authentication, or failed to connect. Right after step 2 you should expect "needs authentication", and that is the correct state.

If you prefer a file over a command, the same server can be described in a `.mcp.json` entry. The package ships this exact shape:

```json
{
  "mcpServers": {
    "firstsales-product": {
      "type": "streamable-http",
      "url": "https://api.app.firstsales.io/mcp"
    }
  }
}
```

Claude Code's own documentation writes the transport type as `http` in its examples, while the package file says `streamable-http`. Use the `claude mcp add` command and let Claude Code write the entry in its own format, so you never have to reconcile the two spellings by hand.

## Step 3: sign in with OAuth

Open a Claude Code session in the project where you want to work. Then run the built-in MCP command.

```text
/mcp
```

Select `firstsales-product`, choose the authenticate option, and finish the sign-in in the browser window that opens. The server advertises OAuth protected resource metadata at `https://api.app.firstsales.io/.well-known/oauth-protected-resource/mcp`, and the authorization server metadata sits at `https://app.firstsales.io/.well-known/oauth-authorization-server`, per the product MCP skill.

You do not need to read those documents to sign in. They matter for a different reason: they prove the sign-in is a standard OAuth flow, so the token Claude Code stores is scoped to the MCP resource and not to your whole account.

The same skill lists the protocol details a security reviewer will ask about. Transport is streamable HTTP. The protocol revision is `2025-11-25`. The client sends `Authorization: Bearer <access-token>` and an `MCP-Protocol-Version: 2025-11-25` header.

Claude Code handles all of that for you. You only need to remember that the bearer token here is an OAuth access token, which is a different thing from the Developer API key you exported in step 1.

When sign-in finishes, run `claude mcp list` again. The label should now read connected.

```mermaid
sequenceDiagram
    participant You
    participant CC as Claude Code
    participant AS as FirstSales sign-in page
    participant MCP as firstsales-product server
    You->>CC: /mcp then authenticate
    CC->>AS: open OAuth with PKCE in the browser
    You->>AS: approve access
    AS-->>CC: access token for the MCP resource
    CC->>MCP: tools/list with bearer token
    MCP-->>CC: tools your grant allows
    CC-->>You: connected, tools loaded
```

## Step 4: read the tool list your grant received

This is the step most guides skip, and it is the one that makes the setup safe.

The `firstsales-product-mcp` skill says to treat authenticated `server/discover` and `tools/list` as the live authority for the current tenant and grant. In plain terms, the tool list is per account and per permission set, so a list you saw in someone else's screenshot may not match yours.

The MCP specification backs this up. Its tools page describes `tools/list` as the request a client uses to discover what a server offers, and a server can return different tools to different callers.

In Claude Code you do not call `tools/list` by hand. Ask for it in the session.

```text
List every tool you received from the firstsales-product server.
For each one, give the exact tool name, a one-line description,
and say whether it reads data or changes data.
Do not call any of them.
```

Read the answer slowly. Look for three things: the names, the read-versus-write split, and anything you did not expect.

In one connected session, the FirstSales team confirmed tools for these areas. Your list may be shorter or longer.

| Area | Confirmed in one connected session | Changes data? |
|---|---|---|
| Campaigns | list, get | ✗ no |
| Campaign workflow | get, update | ✓ update changes data |
| Campaign analytics | analytics, progress, events | ✗ no |
| Contacts | create | ✓ yes |
| List membership | update | ✓ yes |
| Blocked domains | list, add | ✓ add changes data |
| Companies | list, get | ✗ no |
| Deals and pipelines | deals list/get, pipelines get | ✗ no |
| Activities | list | ✗ no |
| Team members | list | ✗ no |
| Billing | credit balance, credit history, usage | ✗ no |

Two things stand out in that table. First, campaign creation is not on it. Second, the product skill describes the released catalog as read-only today, while the confirmed session also showed a few write tools, so your own `tools/list` decides which description applies to you.

Do not resolve that conflict by guessing. Resolve it by reading your list, and write down which write tools you have. If your list contains no write tools, everything in this guide that edits data happens through the CLI instead.

Creating a campaign is a CLI job in every case. The command is `firstsales campaigns create`, and you then use MCP to edit and watch the campaign. The follow-up post on [building a cold email campaign from Claude Code](/blog/claude-code-cold-email-campaign) walks through that order.

If your tool list looks large, read [why 100 MCP tools make an agent worse](/blog/too-many-mcp-tools) before you add more servers beside this one. Every extra tool competes for the model's attention.

## Step 5: run the three-prompt smoke test

A smoke test proves the connection returns true data. It uses read-only prompts, and it compares each answer with the ground truth you saved in step 1.

**Prompt one: count and name.**

```text
Using the firstsales-product server, list my campaigns.
Return the count and the name and status of each one.
```

Compare the count with the `firstsales campaigns list` output you saved. A match means the model is reading the same workspace as the CLI. A mismatch usually means you signed in to a different organization or workspace than your API key points at.

**Prompt two: one campaign in detail.**

```text
Pick the campaign named <one of your campaign names>.
Get its details and its progress. Quote the raw fields you used.
Do not summarize anything you did not read from a tool result.
```

The last instruction matters. It trains you, and the model, to separate "what the tool returned" from "what the model inferred". When you later ask for analysis, that separation is what keeps the numbers honest. The post on [asking Claude how your campaign is doing](/blog/campaign-analytics-in-claude) builds on this habit.

**Prompt three: a refusal check.**

```text
Delete my oldest campaign.
```

Yes, this is a deliberate bad request. The correct outcome is that the model finds no delete tool for campaigns, says so, and does nothing. If it proposes a workaround, such as calling a raw API route, stop the session and tighten your permissions in the next section.

You are not testing the model's politeness here. You are testing whether the combination of tool list, permission settings and instructions produces a safe refusal. Run this test once per project, and again whenever your tool list changes.

Record the result in a short note. Date, tool names seen, three prompts, three outcomes. That note becomes your baseline.

## Pick the right scope

Claude Code stores a server definition in one of three scopes. The [documentation](https://code.claude.com/docs/en/mcp) says commands write to local scope unless you add `--scope project` or `--scope user`.

| Scope | Where it lives | Who sees it | When to choose it |
|---|---|---|---|
| local (default) | `~/.claude.json`, under the project entry | only you, only this project | trying the server for the first time ✓ |
| project | `.mcp.json` at the repo root | everyone who clones the repo | a team that shares one outbound workspace ✓ |
| user | `~/.claude.json`, global | only you, every project | a personal operator who works across many repos ✓ |

Start with local. It limits the blast radius while you read the tool list and run the smoke test.

Move to project scope only after the whole team agrees on the same tool list. The `.mcp.json` file contains no secret, because sign-in uses OAuth and each person authenticates on their own. That makes it safe to commit, and the documentation says Claude Code asks for approval before it uses a project's servers for the first time.

A shared file also creates a shared assumption. If you commit it, you are telling every teammate that this server belongs in the project, so mention the smoke test in the repo's README or its `CLAUDE.md` rules file.

User scope is convenient for a single operator. The cost is that the server follows you into repositories where you never meant to talk about outbound, and a stray prompt in an unrelated project can reach your campaigns.

If you ever need to undo a choice, `claude mcp remove firstsales-product` removes the entry. Add `--scope` when the same name exists in more than one place.

## What MCP does and what the CLI does

Both surfaces talk to FirstSales, but they were built for different jobs. Confusing them is the second most common setup mistake after mixing up credentials.

| Job | Use MCP | Use the CLI |
|---|---|---|
| Ask what a campaign is doing | ✓ analytics, progress, events | ✓ `campaigns analytics`, `progress`, `events` |
| Edit a campaign workflow | ✓ workflow get and update, if your list has them | ✓ `campaigns workflow get` and `update` |
| Create a campaign | ✗ not confirmed | ✓ `campaigns create` |
| Check readiness before launch | ✗ not on the confirmed list | ✓ `campaigns readiness` |
| Send a test email | ✗ not on the confirmed list | ✓ `campaigns send-test-email` |
| Start, pause or resume | ✗ not on the confirmed list | ✓ `campaigns start`, `pause`, `resume` |
| Delete anything | ✗ no | ✓ with `--confirm` only |
| Script it in CI or cron | ✗ built for interactive clients | ✓ JSON output and exit codes |

The product skill gives a clean rule for choosing. If a desired action is mutating, destructive, billing-related or approval-backed, switch to the CLI or the Developer API instead of assuming MCP support.

The CLI also carries guards that MCP does not: `--dry-run` previews a request without sending it, `--confirm` gates destructive commands, and `--idempotency-key` makes retries safe. For a longer comparison, the guide on [CLI, MCP or the app](/blog/cli-vs-mcp-vs-app-outbound) maps each job to its best surface.

The practical workflow is a relay. You create and launch with the CLI, because those steps need deliberate gates. You then edit and monitor with MCP, because those steps benefit from conversation.

Before any campaign goes live, two CLI commands are non-negotiable. Run `firstsales campaigns readiness` and `firstsales campaigns send-test-email` before `firstsales campaigns start`. Claude Code can run those commands for you in a terminal session, but you read the results and you decide.

For the full pre-launch routine, see the [pre-launch checklist from the terminal](/blog/campaign-readiness-check-cli) and the guide to [sending a test email from Claude Code first](/blog/send-test-email-claude-code).

## Permissions inside Claude Code

Claude Code asks before it runs tools it has not been allowed to run. Keep that default for the first week.

When the prompt appears, read the tool name and its arguments. If the tool is a read tool and the arguments match what you asked for, approve it. If the tool changes data, pause and ask yourself whether you would have clicked the same button in the FirstSales app.

The MCP specification gives the reason. Its tools page says there SHOULD always be a human in the loop with the ability to deny tool invocations, and it asks applications to present confirmation prompts so that a human stays in the loop.

Two habits keep this workable without nagging yourself into approving everything blindly.

First, allow read tools you use all day, such as campaign list and campaign progress, and leave write tools on "ask every time". Claude Code supports allow and deny rules in its settings, and the Claude Code settings documentation describes the file locations.

Second, write your standing rules where the model reads them every session. A short `CLAUDE.md` section works well:

```text
FirstSales rules for this project
- Never start, pause or resume a campaign. Print the CLI command and stop.
- Before any write tool, show me the exact change and wait for a yes.
- Quote raw tool fields when reporting numbers.
- Never ask me for an API key. Never print environment variables.
```

These rules are instructions, not enforcement. A model can drift from them in a long session, which is why the permission prompt remains the real gate. The post on [guardrails for email-sending agents](/blog/email-agent-guardrails) explains why you want both a written rule and a technical block.

For a deeper look at which tools an agent should hold at all, read [MCP tool permissions for sales](/blog/mcp-tool-permissions-sales). The short version: give an agent the smallest set that finishes the job.

## Troubleshooting a failed connection

Most failures fall into a handful of patterns. This table covers what you are likely to see.

| Symptom | Likely cause | What to do |
|---|---|---|
| `claude mcp list` shows needs authentication | You added the server but did not sign in | Run `/mcp`, choose the server, authenticate ✓ |
| Sign-in page opens, nothing happens afterward | A popup blocker stopped the redirect | Allow the page, run the authenticate step again ✓ |
| Tools return 401 later | The token expired or was revoked | Re-authenticate from `/mcp` ✓ |
| Failed to connect | Typo in the URL or a network block | Remove the entry and re-add it with the exact URL ✓ |
| Count differs from the CLI | Different organization or workspace | Compare `firstsales whoami` output with the account you signed in to ✓ |
| A tool you expected is missing | Your grant does not include it | Read your own tool list; use the CLI for that job ✓ |
| `unsupported_operation` from the CLI | The surface is not public yet | Stop and report it; do not call app-private routes ✓ |

Notice what the table never recommends: pasting a key into the chat to "fix" authentication. Product MCP does not accept Developer API keys, so a key can only leak, never help.

The Claude Code documentation covers the list command and its status labels in detail. When a problem survives the table, remove the server and add it again from scratch, because a clean entry rules out a stale config.

Run `firstsales doctor --pretty` too. If the CLI also fails, the problem is the account or the network, not Claude Code.

## A first-week routine

Setup is a one-time task, but trust builds over days. This routine keeps the first week deliberate.

**Day one.** Finish the five steps. Save the tool list and the smoke-test note. Do not edit anything.

**Day two.** Ask only questions. Which campaigns are active? Which one has the most sends this week? What happened in the last 24 hours on one campaign? Compare each answer with the app or the CLI.

**Day three.** Practice the CLI half. Run `firstsales campaigns get`, `progress` and `analytics` for one campaign, then ask the model to explain the same data. You are learning where the two views agree.

**Day four.** Make one small, reversible edit through MCP, if your list allows it. Read the campaign workflow first, change one thing, and read it again afterward. The guide to [editing a campaign workflow by chatting with Claude](/blog/edit-campaign-workflow-with-claude) shows how to do this with a diff.

**Day five.** Review what the agent did. Which tools did it call most? Did it ever reach for something you did not expect? Remove tools or tighten rules based on what you see.

A weekly review like this follows the same logic as [human-in-the-loop cold email](/blog/human-in-the-loop-cold-email): automation earns more freedom only after a person has watched it work.

If you plan to go further, the guide to [running outbound from the terminal](/blog/outbound-from-the-terminal) describes the full operating model, and [the stack in five layers](/blog/ai-outbound-agent-stack) shows where this connection sits among the others.

## When the tool list changes

Tool lists change. The specification includes a `listChanged` capability, which a server can use to tell clients that its tools were added or removed. Your grant can change too, for example when an admin adjusts access.

A silent change is a risk because your smoke-test note describes yesterday's list. The post on [MCP security for outbound](/blog/mcp-security-outbound) covers pinning and review in depth.

For a small team, a light process is enough. Re-run prompt one in step 5 each Monday. Re-run all three prompts after any announced FirstSales release or any change to your permissions.

Keep a short log, even a plain text file in the repo. A log turns "it behaved differently last week" into a question with an answer.

Also watch the sending side of your own program, because the model reads and edits, but mailbox providers judge the result. Google's [email sender guidelines](https://support.google.com/mail/answer/81126) ask senders to keep spam rates reported in Postmaster Tools below 0.10% and to avoid ever reaching 0.30%, and they require one-click unsubscribe for marketing and subscribed messages from senders above 5,000 messages a day to Gmail accounts.

Those numbers belong in your weekly review next to the tool list. Our post on the [spam complaint rate threshold](/blog/spam-complaint-rate-threshold) explains how to read them, and the [Google bulk sender rules for 2026](/blog/google-bulk-sender-rules-2026) covers the requirements in full.

## Five mistakes that cost an afternoon

These come up often enough to deserve their own list. Each one is cheap to avoid once you know it.

**Mistake one: trusting the green label.** A connected server proves a handshake succeeded. It does not prove the model reads the workspace you think it does. The smoke test in step 5 is the only check that compares the model's answer with a second source.

**Mistake two: treating a screenshot as the tool list.** A blog post, a chat message or a colleague's terminal shows one account's grant at one moment. Your own list decides what you can call, so read it yourself.

**Mistake three: giving one key every scope.** When you create the Developer API key for the CLI, pick the narrowest scopes that cover today's work. You can create a second key tomorrow for a wider job, and you can revoke the first with `firstsales api-keys revoke`.

**Mistake four: asking for a campaign to be created through chat.** Creation belongs to `firstsales campaigns create`. If you ask the model to create one through MCP, the best outcome is a polite refusal and the worst is an improvised workaround, so keep the request out of the chat.

**Mistake five: skipping the pre-launch pair.** Run `firstsales campaigns readiness` and `firstsales campaigns send-test-email` before `firstsales campaigns start`, every time, even for a copy of a campaign that launched fine last month. Mailbox settings, domains and content all drift between launches.

## A sample session, line by line

Here is how a calm first session reads once everything is connected. The prompts are yours, and the notes show what to check.

Start with the scope of the session, so the model knows the rules before it touches a tool.

```text
We are working in the FirstSales workspace named <your workspace>.
Read-only for now. List my campaigns, then wait.
```

The model calls the campaign list tool and prints names and statuses. Compare the count with your saved CLI output. If they match, move on.

Next, ask for one campaign in detail and make the model show its evidence.

```text
For the campaign named <campaign name>, get progress and analytics.
Print the raw field names you received before you interpret anything.
```

Printing field names first sounds fussy, but it pays off the first time a field is named differently from what you assumed. You learn the real schema from the tool itself, not from memory.

Then ask the one question that tests judgment.

```text
Which of these numbers could mislead me, and why?
```

A good answer points at missing denominators, tiny samples and metrics that bots can inflate. If you want to see why, read about [bot clicks and fake engagement](/blog/bot-clicks-fake-email-engagement) and the case against [open rates as a decision metric](/blog/email-open-rates-dead-metrics).

Last, close the session with a summary you can paste into your notes.

```text
Summarize what you read, which tools you called, and what you changed.
The answer to "what you changed" should be nothing.
```

If the final line comes back with anything other than nothing, stop and look at the tool-call history before you do anything else.

## What to put in your project notes

Keep a short `FIRSTSALES.md` or a section in `CLAUDE.md` with the facts a new teammate, or a new session, would otherwise rediscover. Five lines cover it: the organization and workspace identifiers, the date of your last smoke test, the list of tools you have, the list of tools you refuse to use, and the name of the person who approves launches.

That last line matters more than it looks. An outbound program with an agent in it still needs a named human who says yes. The same idea runs through the guide to [automated pre-send checks](/blog/automated-pre-send-checks-cold-email), where checks run by machine and the launch decision stays with a person.

## FAQs

### How long does it take to connect FirstSales MCP to Claude Code?

About five minutes if Claude Code and Node are already installed. Installing the CLI, adding the server, signing in through OAuth and reading the tool list are the four timed steps.

### What is the exact command to add the server?

Run `claude mcp add --transport http firstsales-product https://api.app.firstsales.io/mcp`. Then open `/mcp` in a session to sign in.

### Do I need the CLI to use the MCP server?

No, the server works without it. The CLI is worth installing anyway because creating campaigns, running readiness checks, sending test emails and starting campaigns all happen there.

### Does the MCP server use my Developer API key?

No. The product MCP skill says Developer API keys and dashboard cookies are not accepted. MCP signs in with OAuth and PKCE.

### Where do I find the live list of tools?

Ask Claude Code to list the tools from the `firstsales-product` server without calling them. The live `tools/list` response is the authority for your account and grant.

### Can Claude Code create a campaign through MCP?

Campaign creation has not been confirmed through MCP. Create the campaign with `firstsales campaigns create`, then edit and monitor it through MCP.

### Why does the connected list differ from what a colleague sees?

The tool list is per tenant and per grant. Different accounts and permission sets receive different tools.

### Which scope should I pick first?

Local scope. It limits the setup to you and one project while you learn the tool list.

### Is it safe to commit `.mcp.json`?

The file holds a server name, a type and a URL, and no secret, because sign-in uses OAuth. Teammates still authenticate individually.

### What does "needs authentication" mean after I add the server?

The entry exists, but you have not signed in. Open `/mcp`, choose the server and authenticate.

### How do I remove the server?

Run `claude mcp remove firstsales-product`. Add the scope option if the same name exists in more than one scope.

### Should I let Claude Code approve tool calls automatically?

Keep prompts on for write tools. Allowing frequent read tools is reasonable once your smoke test passes.

### What should I do before starting a campaign?

Run `firstsales campaigns readiness` and `firstsales campaigns send-test-email`, then read the results. Only then run `firstsales campaigns start`.

### Can I delete contacts from Claude Code?

The CLI has `contacts delete`, and it requires `--confirm`. Deletes cannot be undone, so keep deletes out of the agent's allowed actions.

### Where should I store my Developer API key?

Store it in an environment variable. Never paste it into a prompt, a chat, a file in git or a post.

### What if the CLI returns `unsupported_operation`?

The surface is not part of the public Developer API yet. Stop and report it instead of calling app-private routes.

### How often should I re-check the tool list?

Check it weekly and after any release or permission change. A five-line log makes drift easy to spot.

### Does MCP work in tools other than Claude Code?

Yes. Any MCP-aware client can connect to the same endpoint, and the OAuth steps differ by client. This guide covers Claude Code only.

### What is the difference between MCP and a skill?

MCP exposes live tools from a server. A Claude Code skill is a folder of written instructions that the model loads when relevant, and the CLI package ships three of them.

### What should I read after this guide?

Read [building a cold email campaign from Claude Code](/blog/claude-code-cold-email-campaign) next. It uses the connection you just made.

## Conclusion

You now have a working connection and, more usefully, a record of what it can do. The steps are short: install the CLI, add `firstsales-product`, sign in with OAuth, read the tool list, and run three read-only prompts.

Keep three rules from this post. Use the CLI for creating, checking and launching. Use MCP for editing and watching. Never let an API key near a prompt.

Treat the smoke-test note as a living document. Update it each Monday and after every permission change, and your setup stays an answer instead of an assumption.

The next step is the first campaign. Follow [Build a cold email campaign from Claude Code](/blog/claude-code-cold-email-campaign), then use [the daily outbound standup prompt](/blog/daily-outbound-standup-prompt) to keep watch.

Ready to try it? Create a FirstSales workspace, install `@firstsales.io/cli`, and run the five steps today. Start with `firstsales whoami --json`.