Linkedin MCP Server

gtm-api: LinkedIn MCP Server

gtm-api is a managed LinkedIn MCP server. It gives an AI agent one endpoint, three MCP tools and 160+ typed LinkedIn actions over the Model Context Protocol, so Claude, ChatGPT or Cursor can search, connect, message and enrich on a LinkedIn account you own, with account safety enforced server side.

This repository holds the public interface: what the server exposes, how to connect a client, and how the safety layer works.

What is a LinkedIn MCP server?

A LinkedIn MCP server exposes LinkedIn actions as Model Context Protocol tools, so an AI agent calls them directly, the way a person would click through the UI. LinkedIn publishes no official API for invitations, member messages or open profile search, so a LinkedIn MCP server works through an account you own rather than through LinkedIn's developer platform.

Two shapes exist today. Cookie-driven open-source servers run a browser session with your own cookie and no pacing. Managed servers run each account in isolated infrastructure with limits enforced before every action. gtm-api is the second kind.

Which clients it works with

Any MCP-compatible client:

• Claude (Desktop, Code, and the API)
• Cursor
• ChatGPT (via connectors)
• LangChain, n8n, and custom agent runtimes

Not using MCP? Every tool is also a typed REST endpoint with webhooks. One schema generates all three surfaces.

Quickstart

1. Sign up. Create an account at app.gtm-api.com (forever free plan, no card) and connect a LinkedIn account. It opens in a dedicated anti-detect cloud browser with its own proxy.

2. Add the server to your MCP client. For Claude Desktop, edit claude_desktop_config.json (example in examples/):

{
  "mcpServers": {
    "gtm-api": {
      "url": "https://mcp.gtm-api.com/mcp"
    }
  }
}

There is no key to paste. The endpoint authenticates with OAuth: your client gets a WWW-Authenticate challenge on the first call, registers itself with the authorization server (dynamic client registration), and opens a consent page in your browser. An API key (gtm_live_...) authenticates the REST API instead, and answers 401 invalid_token here.

Client can only spawn a command, not open a URL? The @gtm-api/linkedin-mcp launcher bridges stdio clients to the same endpoint and runs the same OAuth flow (config in examples/):

{
  "mcpServers": {
    "gtm-api": {
      "command": "npx",
      "args": ["-y", "@gtm-api/linkedin-mcp"]
    }
  }
}

For Claude Code it is one line: claude mcp add --transport http gtm-api https://mcp.gtm-api.com/mcp.

The same launcher also ships as a Docker image, gtmapi/linkedin-mcp (config in examples/). Mount a volume on the token cache so the consent step runs once rather than on every container:

{
  "mcpServers": {
    "gtm-api": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-v", "gtm-mcp-auth:/home/node/.mcp-auth", "gtmapi/linkedin-mcp"]
    }
  }
}

3. Restart the client and prompt in plain English:

"Every morning, accept new connection invitations from founders, reply with a short welcome, and add anyone hiring SDRs to a warm list."

The agent discovers the actions and chains them: fetch the latest connection invitations, accept the ones that match, send each new contact a short message. Every outward action runs a preview-then-confirm step and a server-side daily-limit check before it reaches LinkedIn.

MCP tools

The server exposes exactly three MCP tools. Discovery is progressive: an agent lists the toolsets, inspects one, then invokes an action. The 160+ LinkedIn actions never load into the model's context at once, so the schema footprint stays around 400 tokens.

[
  {
    "name": "list_toolsets",
    "description": "List the available toolsets (domains) on this server. Each toolset groups related tools (e.g. linkedin.messaging, id.billing). Start here, then get_toolset_tools to inspect one, then call_tool to run a tool. Requires OAuth authorization (Bearer token).",
    "input_schema": { "type": "object", "properties": {} }
  },
  {
    "name": "get_toolset_tools",
    "description": "List the tools in a toolset. Default (lite) returns name + title + one-line summary; pass verbose:true for full descriptions, safety flags, and parameter names. Run one via call_tool.",
    "input_schema": {
      "type": "object",
      "properties": {
        "toolset": { "type": "string", "description": "Toolset id from list_toolsets, e.g. \"linkedin.messaging\"." },
        "verbose": { "type": "boolean", "description": "Include full descriptions + parameter names." }
      },
      "required": ["toolset"]
    }
  },
  {
    "name": "call_tool",
    "description": "Invoke a tool by name (discovered via get_toolset_tools) with its arguments object. Behaves exactly like calling the tool on its domain mount. Dangerous tools still require the two-step preview→confirm (pass commit_token inside arguments on the confirm call).",
    "input_schema": {
      "type": "object",
      "properties": {
        "name": { "type": "string", "description": "Exact tool name." },
        "arguments": { "type": "object", "description": "The tool's arguments object." }
      },
      "required": ["name"]
    }
  }
]

call_tool validates arguments against the target action's own input schema, so preview-then-confirm, rate limits and typed errors apply exactly as if the action were mounted directly.

What the agent can do

160+ typed actions across 10 LinkedIn toolsets, grouped here into seven areas:

LinkedIn is the live channel today. Email (Gmail, Outlook, IMAP), messengers (WhatsApp, Telegram, Instagram DMs) and calendars (Google, Microsoft) are on the roadmap on the same typed contract.

Is it safe for my LinkedIn account?

Safety is enforced by the server itself, under every tool call. Six mechanisms:

• Owned accounts. The agent acts through an account you connected and control. There is no shared account pool.
• Session isolation. Each account runs in its own anti-detect cloud browser with a dedicated proxy. One account, one session, one device signature.
• Warm-up. A new account starts at a fraction of platform maximum, and its allowance is raised programmatically as the account ages and builds history.
• Server-side limits. Per-action daily budgets are checked before dispatch, across 16 action buckets.
• Randomized pacing. Bulk work is spread with per-gap randomized intervals, because a fixed cadence is itself a detectable pattern.
• Preview then confirm. Outward actions return a preview and require confirmation, so an over-eager agent cannot burn an account.

On this setup gtm-api reports 20,000+ LinkedIn accounts running at under 1% monthly ban. Full method: gtm-api.com/safe-linkedin-automation.

How it compares to open-source LinkedIn MCP servers

Cookie-driven servers such as stickerdaniel/linkedin-mcp-server run a browser session with your own LinkedIn cookie and leave pacing to you: the project's README documents the cookie login flow and lists no rate limiting. Apify's LinkedIn actors are a different shape, hosted scrapers priced per result and focused on pulling data out.

Pricing

Volume pricing per connected account per month, from $10/account at scale, with unlimited API calls and no per-action fees. Forever free plan, no card: gtm-api.com/pricing.

A note on LinkedIn's terms

LinkedIn's User Agreement does not permit third-party automation, so every tool in this space carries risk and no vendor can honestly promise otherwise. gtm-api reduces that risk by acting only on accounts you own, with warm-up, human-like pacing and enforced limits, which is why the reported ban rate is under 1%. This is not legal advice.

Links

• Sign up (forever free plan): app.gtm-api.com
• Connecting any client, step by step: docs.gtm-api.com/mcp/connect
• How a LinkedIn MCP server works: gtm-api.com/linkedin-mcp-server
• The safety method in detail: gtm-api.com/safe-linkedin-automation
• npm launcher: npmjs.com/package/@gtm-api/linkedin-mcp
• Docker image: hub.docker.com/r/gtmapi/linkedin-mcp
• Model Context Protocol: modelcontextprotocol.io

---

gtm-api.com, the LinkedIn API and MCP server for AI agents.