Sign in Talk to AI Sales Start free

Outreach MCP server: run GetSales from Claude, Cursor or ChatGPT

One hosted endpoint connects your GetSales workspace to any MCP client. What it exposes, how to set it up in each client, what the paid work costs, and what stops to ask you first.

Updated November 2026 · 17 min read · GetSales team

Your prospecting sits in one tab and your agent sits in another. The GetSales outreach MCP server closes that gap: one hosted endpoint, https://mcp2.getsales.io/mcp/public, and Claude, Cursor or ChatGPT can build a table of the people you sell to, price an enrichment run before it spends a credit, draft a workflow for you to approve, and tell you which replies are waiting. You paste no key. The first call opens a GetSales consent screen in your browser, you pick the workspaces the client may act in, and that is the setup.

What follows: what the server puts in front of an agent, the exact setup for each client, three prompts with what comes back, which calls stop and ask you first, what the paid work costs, and the limits you will meet.

What the GetSales outreach MCP server is

It is a remote Model Context Protocol server that exposes the objects of your GetSales workspace as tools, so an agent in a chat window can do what a person does in the app: find the right people, enrich them, score them, put them into a sequence and keep up with the replies. The transport is streamable HTTP, stateless, JSON-RPC over POST,[1] and the endpoint answers as gs-mcp-public 2.0.0, offering protocol revision 2025-11-25 and accepting the older ones back to 2024-11-05. GetSales runs the server, so there is nothing to host and nothing to update.

Four meta-tools stand in front of everything else. search_tools finds a tool from a plain description of the job, describe_tool returns one full definition, call_tool runs a tool by name, and list_toolsets is the map. The agent searches, reads the definition it picked, then calls. The point of that shape is budget: on 13 November 2026 the server's own health endpoint counted 260 tools on the public endpoint, and loading 260 definitions into a context window before the first useful sentence would cost more than the work.

Published in three places, all of them checkable:

  • The hosted endpoint, https://mcp2.getsales.io/mcp/public, live since 8 November 2026.
  • The npm launcher and the image, @getsales/outreach-mcp 1.0.0 and getsalesio/outreach-mcp at tags 1.0.0 and latest, both published 8 November 2026.
  • The MCP Registry entry io.getsales/outreach-mcp 1.0.0, whose namespace is proven by a DNS record on the getsales.io apex.[2] The client configs, the launcher source, the plugin manifests and an agent skill are in the public kit repository.[3]

Connect it in Claude, Cursor or ChatGPT

Every interactive client takes the same URL and runs the sign-in itself. The first call answers 401 with a WWW-Authenticate header naming the server's protected resource document.[4] The client reads the authorization server from it, registers itself with no credential agreed in advance[5], and opens the GetSales consent screen. Your password never reaches the client.

Claude Code, one command:

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

Then run /mcp in a session and sign in when it asks.

claude.ai and Claude Desktop[6]: Settings, Connectors, Add custom connector, name it GetSales, paste the URL, then Connect. A Claude Desktop install that is configured by file takes the bare URL:

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

Cursor: Cursor Settings, MCP, Add new MCP server, or the same four lines in .cursor/mcp.json. Cursor shows a Connect button on the server and runs the browser sign-in.

ChatGPT: Settings, Connectors, Create, the URL, authentication OAuth. On Business and Enterprise workspaces an admin may have to allow custom connectors first.

Codex: codex mcp add getsales --url https://mcp2.getsales.io/mcp/public, then codex mcp login getsales.

A headless client with no browser at hand sends an API key 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_..."

A client that can only start a command runs the launcher, which does the same browser sign-in, or reads GETSALES_API_KEY from its environment when you put a key there. The key goes to the server as the bearer and never onto a command line, so it stays out of process lists and client logs:

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

The Docker image runs that launcher with a key only. The browser sign-in cannot finish inside a container, because the consent page sends your browser back to localhost, which is your own machine, while the bridge waits for that answer on the container's loopback. Keyless, the container stops at once and says so.

The repository is also a Claude Code and a Cursor plugin, and it carries an agent skill beside the server. The skill teaches the agent three habits that are worth having: read a tool's full definition before calling it, quote the cost of paid work and wait for a yes, and read an error code before trying again.

Three prompts and what comes back

The first one is the shape most people start with:

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 searches the catalog, creates the table, attaches an AI search as its source, adds the Find work email column, calls estimate_credits for the run, and stops on the number. Nothing has been spent at that point. You answer, and it starts the run with a budget cap.

The second is the one that pays for the connection on a Monday morning:

Which threads are waiting for me, and what did the AI SDR draft for each?

That reads the inbox toolset: the threads with an unanswered counterpart, each one's last message, the draft the AI SDR wrote and the label it gave the reply. The agent can summarise all of it in one message, which is the part a web inbox cannot do for you.

The third puts a change behind a confirm:

Draft a workflow for the Q4 view: an email, two days of waiting, a follow-up. Show it to me before you publish.

Authoring and validating the workflow runs freely. Publishing it is marked dangerous, so the first publish call changes nothing and answers a preview with a commit_token, and the agent has to call again with that token to make it real.

Others worth trying once you are connected: "How is the Berlin agencies table doing this month, and where do people drop out?", "Who visited the pricing page this week and has not replied?", "How many credits are left, and what did last week's enrichment spend?", "Subscribe our endpoint to new replies and fire a test event."

The toolsets it exposes

The tools are grouped by the part of the product they work on, and the agent loads only the group a task needs. Nineteen toolsets on 13 November 2026, in four areas. The counts move with each release, so list_toolsets is always the current answer.

Toolset What the agent works with
playtables.tables Tables, saved views, and how each table is doing
playtables.columns Enrichment and AI columns, cells, runs, cost estimates
playtables.rows People, companies, and the feed of what happened to each
playtables.crm Pipeline stages, notes, tags, the do-not-contact list
playtables.sources Where rows come from: AI search, CSV imports, webhooks
playtables.workflows Workflows: authoring, validation, publishing, pause and resume
playtables.workflow-records Where each person stands in a workflow, and its tasks
inbox Threads, messages, the AI SDR's drafts, tasks, the person timeline
sender-profiles Your sender profiles, their variables, and what each did day by day
ai-sdr.agents Your team's AI SDR agents, their scenarios, plans and runs
ai-sdr.training The answers the AI SDR gives, their source documents, and what it learned
signals Sessions and visitors identified to a person or a company, and the plays that react
workspace.team Account, workspaces, members, invitations, the notification feed
workspace.access The API keys that stand, and the apps a person connected
workspace.billing Subscription, invoices, payment methods, credit balance and spend
workspace.website-tracking Tracking setup: sites, key pages, tracked events, settings
workspace.integrations Data providers and their prices, your own connections and HTTP tools
workspace.webhooks Webhook subscriptions and their deliveries
workspace.whitelabel White label brands, client workspaces, certificates

A sender profile is the identity your team sends as, with its LinkedIn account and its mailboxes. The server drives the workspace and never acts on a channel itself. The public endpoint carries no tool that sends a message, none that approves and sends an AI SDR draft, and none that connects a LinkedIn account or a mailbox. Accounts are connected in the app, and a workflow you publish does the sending.

What stops and asks you, and what runs at once

Two different guards, and the difference matters when you let an agent work unattended.

Dangerous tools preview first. The first call changes nothing and answers what would happen, with a commit_token. The same call with the same arguments plus 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: every delete and cancel, a conversation merge, a thread's counterpart put on the stoplist, a site key or ingest key rotated, a subscription change, a connected app revoked, a webhook created, changed or replayed, publishing or resuming a workflow, a person resumed, restarted or taken out of one, a company taken off a table, a visitor unlinked from a person, and an AI SDR agent changed or reset.

Paid work has no preview. A table run with type enrich spends credits as it goes. estimate_credits prices it first and max_budget caps it, and a run sent with no max_budget has no cap. An AI search source spends credits on its result pages with no estimate and no cap. A column set to run by itself fills every row that lands, outside any run's budget, held only by that column's own daily credit cap when you set one. A bulk run can delete rows or move them to another table. A company merge moves one company's leads onto another, and nothing takes that back.

The skill in the repository tells the agent to say what a step will do, quote the cost, and wait. Treat it as a habit the agent has, and set a daily cap on any column you leave running.

What it costs

Connecting is free. The pricing page[7] lists API, webhooks, MCP and CLI on the free Playtables and Data plan, which comes with 3 tables, 15,000 rows and 50 columns and runs on your own provider API keys. The server is the same contract either way, so a free workspace reaches every read tool and every tool that changes something in the workspace.

What spends money is the data work behind the tools: email finding and verification, AI columns, the Find people column, and the pages an AI search returns. Those draw data credits from the workspace balance at the rates on the pricing page, or go to your own provider keys when you bring them. Two tools make the cost readable from inside the agent: estimate_credits names the range of a table run before it starts, and list_provider_catalog holds the price of each provider and model.

Limits, errors and trace ids

The numbers you will meet, read from the server's own health endpoint on 13 November 2026: 600 calls and 120 writes a minute per workspace, at most 16 messages in one batch, 25 seconds per backend call, and answers trimmed to 48,000 characters with a note when they were.

A refused call comes back as a tool result with isError: true and a typed envelope, one of 16 codes in error.code, so a client reads the code and never parses prose. validation_failed names the field and the rule it broke. forbidden names the permission the credential lacks. payment_required means the workspace subscription is on hold or its plan has no room for the step.

A 429 arrives in two kinds, and they want opposite things from you. One carries context.retry_after: too many calls, or a backend asking for a pause. Wait the time it names, then batch the work into fewer calls. The other carries context.resource and no retry time: a cap of the plan or of concurrency, such as how many runs a team may have going at once. Waiting does nothing for that one. It clears when the resource frees.

Every answer carries the request's trace id, in the X-Trace-Id response header and in _meta.trace_id on each tool result. Quote it when you report a problem and support can find the request.

Keys, permissions and revoking access

The browser sign-in suits anything interactive. The person signs in on the GetSales consent screen, picks the workspaces the client may act in, and clicks Allow. The client refreshes its own token. A workspace revokes the connection under Settings, Connected apps, and the client stops working the moment it does.

An API key suits CI, a server or a script. A gs_live_ key is made under Settings, API keys, shown once, and belongs to one workspace. It expires after three years unless it is made without an expiry, and it rotates in place: the old secret keeps working for 24 hours by default, so a config can change with no downtime. Permissions travel with the credential. A key holds an explicit list of permission tokens, always inside the grant of the person who made it, and it can be narrowed to some sender profiles and tables. A call outside that grant answers 403 with the permission it needed.

One key works on this server and on the REST API.[8] A few endpoints have no tool at all, the one that mints an API key among them, so a secret never passes through a model.

MCP server or REST API

Both are one contract: each tool maps to one REST endpoint with the same shapes, the same error envelope and the same key. The question is who is calling.

MCP server REST API
Who calls it An AI agent, from a chat or an agent runtime Your own code
Address One endpoint One base URL per service
Finding a call search_tools over the catalog, at runtime The API reference[9]
Deletes and cancels A preview, then a confirm with a token Run at once
Sign-in Browser consent, or an API key An API key, or an access token

Write a nightly sync against the REST API. Hand the agent the MCP server for the work that changes shape every time you do it.

FAQ

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. The GetSales one is hosted, so there is no server to run yourself.

Do I need a paid plan to connect it?

No. The pricing page lists API, webhooks, MCP and CLI on the free Playtables and Data plan, which gives you 3 tables, 15,000 rows and 50 columns on your own provider API keys. Paid data work, such as email finding or an AI search, draws data credits from the workspace balance, and the agent can price it with estimate_credits before anything starts.

Which clients work with it?

Any client that speaks streamable HTTP or can start a command. Tested and documented: claude.ai, Claude Desktop, Claude Code, Cursor, ChatGPT custom connectors, VS Code and Codex. Clients that only run a command use the npm launcher or the Docker image. A client can hold several MCP servers at once, so this one sits beside whatever else your agent already reaches, and the four meta-tools keep its share of the context small.

Can an agent send messages to my prospects through it?

No. The public endpoint carries no tool that sends a message, none that approves and sends an AI SDR draft, and none that connects a LinkedIn account or a mailbox. What an agent can do is build a workflow and publish it, and publishing is behind a confirm with a single-use token, so the second call is the one that acts. The published workflow then does the sending, from the accounts your team connected in the app.

How do I stop an agent from spending credits by accident?

Three things. Set max_budget on any table run, since a run sent without one has no cap. Set a daily credit cap on any column that fills rows by itself. Keep the bundled agent skill loaded, because it tells the agent to quote the estimate and wait for your yes before it starts paid work. The balance and the spend are readable from the workspace.billing toolset at any time.

Where is the key stored, and how do I revoke access?

With the browser sign-in there is no key: the client holds its own token and the workspace revokes it under Settings, Connected apps. With an API key, the key lives in your client's config or environment, and the launcher passes it as a bearer header so it never lands on a command line. A gs_live_ key is scoped to one workspace with an explicit permission list, can be narrowed to some sender profiles and tables, and rotates in place with a 24-hour grace period.

What happens when a tool call fails?

It comes back as a tool result with isError true and a typed envelope, one of 16 codes in error.code, so a client reads the code and never parses text. validation_failed names the field and the rule, forbidden names the missing permission, and payment_required means the subscription is on hold or the plan has no room. Every answer carries a trace id in the X-Trace-Id header and in _meta.trace_id, and quoting it lets support find the exact request.

Is there a REST API as well?

Yes, and it is the same contract: each tool maps to one REST endpoint with the same shapes and the same error envelope, and one API key works on both. The reference is at docs.getsales.io. Use the API for code you write and schedule, and the MCP server for work an agent shapes differently every time.

Sources

  1. Model Context Protocol, Transports (specification 2025-11-25, the latest revision the endpoint offers): modelcontextprotocol.io/specification/2025-11-25/basic/transports
  2. MCP Registry, the entry io.getsales/outreach-mcp, read 13 November 2026: registry.modelcontextprotocol.io/v0/servers?search=io.getsales/outreach-mcp
  3. GetSales outreach MCP kit: client configs, the launcher, the plugin manifests and the agent skill: github.com/getsales-io/outreach-mcp
  4. RFC 9728, OAuth 2.0 Protected Resource Metadata: datatracker.ietf.org/doc/html/rfc9728
  5. RFC 7591, OAuth 2.0 Dynamic Client Registration Protocol: datatracker.ietf.org/doc/html/rfc7591
  6. Anthropic, About custom connectors (remote MCP servers), read 13 November 2026: support.claude.com/en/articles/11175166-about-custom-connectors-remote-mcp-servers
  7. GetSales pricing, read 13 November 2026: getsales.io/pricing/
  8. GetSales API, authentication and keys: docs.getsales.io/authentication
  9. GetSales API reference: docs.getsales.io

Last updated: November 2026