GetSales: Outreach MCP Server

GetSales: Outreach MCP Server

[Site] [Protocol] [License]

GetSales is LinkedIn and email outreach for agencies and GTM teams, in one app. Describe who you sell to, and GetSales finds the people and their work emails, scores them and writes the first lines, and every reply comes back to a team inbox.

This MCP server lets an AI agent work in your GetSales workspace. Claude, Cursor, ChatGPT or another MCP client connects to one hosted endpoint, https://mcp2.getsales.io/mcp/public, and through four meta-tools reaches the tables of people and companies, the enrichment columns, the workflows, the inbox with the AI SDR's drafts, the tasks, the website signals and the webhooks.

The server runs hosted, so this repository holds its kit and no server code: client configs for the URL, npx and Docker setups, the npm launcher and its image, the MCP Registry entry, the Claude Code and Cursor plugin manifests and an agent skill.

What is an outreach MCP server?

An outreach MCP server puts the objects of an outreach product behind Model Context Protocol tools, so an AI agent can do from a chat what a person does in the app: build a list of the right people, enrich it, put it into a sequence and keep up with the replies. MCP is the open protocol that Claude, Cursor, ChatGPT and other clients use to call tools on a server.

This one works on the objects of your own GetSales workspace. Ask for a table built from one sentence, a work email column priced before it runs, a workflow drafted for the people who qualify, or the threads that wait for you, and the agent chains the calls. The tools the server marks dangerous, such as the delete and cancel tools, show a preview and run only after you confirm. Paid work is not behind that preview, so the skill in this repository has the agent quote the estimate and wait for your yes before it starts any.

Which clients does it work with?

Any MCP client that speaks streamable HTTP or can start a command:

• Claude: claude.ai, Claude Desktop and Claude Code
• Cursor
• ChatGPT, through custom connectors
• VS Code, Codex and other agent runtimes

Not on MCP? Each tool maps to an endpoint of the GetSales REST API, documented at docs.getsales.io, and one API key works on both.

How do I connect GetSales to Claude, Cursor or ChatGPT?

1. Get an account. Sign up for GetSales, or use the workspace you already have.

2. Add the server to your client. Claude Desktop and Cursor read the bare URL from their config file (examples/claude_desktop_config.json, examples/cursor_mcp.json):

{  "mcpServers": {    "getsales": { "url": "https://mcp2.getsales.io/mcp/public" }  }}

In Claude Code it takes one command:

claude mcp add --transport http getsales https://mcp2.getsales.io/mcp/public

On claude.ai, open Settings, Connectors, Add custom connector, and paste the same URL.

You paste no key. The first call comes back with a WWW-Authenticate challenge, the client registers itself (dynamic client registration), and the GetSales consent screen opens in your browser. Sign in, pick the workspaces the client may act in, and click Allow.

A client with no browser at hand (CI, a server, a script) sends an API key instead, made in the app under Settings, API keys:

claude mcp add --transport http getsales https://mcp2.getsales.io/mcp/public --header "Authorization: Bearer gs_live_..."

Use one way per connection. A client that runs OAuth and also sends a fixed header overwrites its OAuth token with that header on each request.

A client that can only start a command runs the launcher (examples/claude_desktop_config.npx.json). It does the same OAuth flow, or uses GETSALES_API_KEY when you put the key in its env. The key goes to the server as the bearer and never onto a command line, so a process list or the client's log of the launcher does not show it:

{  "mcpServers": {    "getsales": {      "command": "npx",      "args": ["-y", "@getsales/outreach-mcp"]    }  }}

The Docker image runs the same launcher and signs in with a key only (examples/claude_desktop_config.docker.json). With -e and the bare variable name, docker hands the container the key from the client's env, and the key stays off the docker command line:

{  "mcpServers": {    "getsales": {      "command": "docker",      "args": ["run", "-i", "--rm", "-e", "GETSALES_API_KEY", "getsalesio/outreach-mcp"],      "env": { "GETSALES_API_KEY": "gs_live_..." }    }  }}

OAuth cannot finish in the container: after the consent page your browser comes back to localhost, which is your machine, while mcp-remote waits for that answer on the container's own loopback. So without a key the container stops at once and says why. For OAuth, give the client the URL or run the npm launcher.

3. Ask in plain words.

"Build a table of heads of marketing at SEO agencies in Germany, add a work email column and tell me what it costs before anything runs."

The agent finds the tools and chains them: a table, an AI search as its source, the email column, the estimate. Then it stops and waits for your word. Every client step by step, ChatGPT, VS Code and Codex included: CONNECT.md.

Can I install it as a Claude Code or Cursor plugin?

Yes. This repository is a plugin for both (.claude-plugin/plugin.json, .cursor-plugin/plugin.json), and it brings two pieces:

• The hosted server at https://mcp2.getsales.io/mcp/public, from .mcp.json.
• The getsales skill and its worked flows. The skill teaches the agent to look a tool up before it calls it, to price paid work and wait for a yes, to show you the preview of a dangerous tool before it confirms, and to read an error before it calls again.

Claude Code loads the plugin from a clone of this repository for one session:

claude --plugin-dir <path to the clone>

For Cursor, copy the plugin files from the clone into Cursor's local plugin folder:

mkdir -p ~/.cursor/plugins/local/getsalescp -R .cursor-plugin .mcp.json skills assets ~/.cursor/plugins/local/getsales/

Then run Developer: Reload Window. The skill and the server show up under Customize.

The plugin holds no key and asks for no settings: the consent page opens on the first tool call.

What can my agent do with it?

The server keeps the tools of the workspace in toolsets, and an agent loads only what a task needs. It calls search_tools with the object and the action in plain words, reads the definition it picked (describe_tool, or search_tools with detail: "full"), then runs the tool through call_tool. list_toolsets is the map.

The toolsets of the workspace, by area:

Playtables: tables, people, enrichment and workflows

The inbox, sender profiles and the AI SDR

Signals

The workspace: the Settings and Admin panels

Things to ask once it is connected:

• "How is the Berlin agencies table doing this month, and where do people drop out?"
• "Which threads are waiting for me, and what did the AI SDR draft for each?"
• "Who visited the pricing page this week and has not replied?"
• "Draft a workflow for the Q4 view: an email, two days of waiting, a follow-up. Show it to me before you publish."
• "How many credits do we have left, and what did last week's enrichment spend?"
• "Subscribe our endpoint to new replies and fire a test event."

Which tools ask for a confirm first?

The ones the server marks dangerous. Their first call changes nothing and answers a preview of what would happen, with a commit_token. The same call again with that token runs it. The token works once, for that tool, those arguments and that workspace, and it expires after 300 seconds. Marked dangerous today: each tool that deletes or cancels something, a conversation merge, a thread's counterpart put on the stoplist, a site key or an ingest key rotated, a subscription change, a connected app revoked, a webhook created, changed or replayed, publishing or resuming a workflow, one person resumed, restarted or taken out of a workflow, a company taken off a table, a website visitor unlinked from a person, and an AI SDR agent changed, one of its scenarios reset or its examples forgotten.

These run on their first call, with no preview:

• Paid work. A table run (create_playtable_run with type enrich) spends credits as it goes. estimate_credits prices it first, and its max_budget caps it, but a run sent without max_budget has no cap. An AI search source (create_data_source) spends credits on its result pages with no estimate and no cap. A column with config.auto_run: true fills each row that lands, outside any run's budget, held only by the column's own daily credit cap when one is set.
• Bulk edits. create_playtable_run with type bulk changes many rows in one call, and its operations include deleting them and moving them to another table.
• A company merge. merge_companies moves the leads of one company onto another, and no tool takes it back.

The skill has the agent say what such a step will do, and its cost when it has one, and wait for your yes. The server answers at most 600 calls and 120 writes a minute per workspace.

What happens when a call fails?

A refusal is a typed envelope with one of 16 codes in error.code, returned as a tool result with isError: true, never prose to parse. validation_failed names the field and the rule, forbidden names the missing permission, and payment_required means the subscription of the workspace is on hold or its plan has no room for the step.

A 429 comes in two kinds. One carries context.retry_after: too many calls, or a backend that asks for a pause. Wait the time it names (seconds at the edge, a timestamp when a backend names its own clock), then batch the work into fewer calls. The other carries context.resource and no context.retry_after: a cap of the plan or of concurrency, such as how many runs a team may have going at once. Waiting does not clear it. It clears when the resource frees, for example when a running run ends.

Each answer carries a trace id: quote it when you report a problem.

How do keys and permissions work?

• OAuth, for interactive clients. The person signs in on the GetSales consent screen, picks the workspaces the client may act in and clicks Allow. The password never reaches the client, and the client refreshes its own token. A workspace revokes the connection under Settings, Connected apps.
• API keys, for headless clients. A gs_live_... key made in the app under Settings, API keys, sent as Authorization: Bearer gs_live_.... The secret is shown once. A key belongs to one workspace and expires after three years unless it is made without an expiry. It rotates in place: the old secret keeps working for 24 hours by default (grace_seconds), so a config can change without downtime.
• Permissions travel with the credential. A key holds an explicit list of permission tokens such as can_view_playtables or can_manage_workflows, always within the grant of the person who made it, and it can be narrowed to some sender profiles and tables (account_sids). A sender profile is the identity your team sends as, with its LinkedIn account and its mailboxes. A call outside the grant answers 403 forbidden with the permission it needed.

One key works on the REST API and on this server. Details: docs.getsales.io/authentication.

What does it cost?

On 2026-11-03 the pricing page lists API, webhooks, MCP and CLI on the free Playtables & Data plan, so connecting the server costs nothing. Paid work spends data credits from the balance of the workspace: enrichment columns such as email finding and verification, AI columns, the Find people column and AI search pages. The pricing page also covers bringing your own provider keys instead. estimate_credits names the cost range of a table run before it starts, and list_provider_catalog holds the price of each provider and model.

How is it different from calling the REST API?

Both are one contract: each tool maps to one REST endpoint with the same shapes. A few endpoints have no tool, such as the one that makes an API key, so that a secret never passes through a model.

What is in this repository?

How the server treats a token, and how to report a problem: SECURITY.md.

Links

• Sign up: getsales.io/signup
• The API reference: docs.getsales.io
• Keys and OAuth: docs.getsales.io/authentication
• Receiving webhooks: docs.getsales.io/guides/receive-webhooks
• The AI sales assistant: getsales.io/ai-sales-assistant
• Pricing: getsales.io/pricing
• Model Context Protocol: github.com/modelcontextprotocol

GetSales is an independent product and is not affiliated with, endorsed by, or sponsored by LinkedIn Corporation. LinkedIn and the LinkedIn logo are trademarks of LinkedIn Corporation. Use of GetSales is at your own risk and subject to the applicable third-party platform terms.