SDR Pilot for GTM Engineers.

The list is not the hard part any more. Getting a message onto LinkedIn, at a human pace, from an account that survives the quarter, is. Every team that builds this themselves goes through the same three months: a headless browser, a proxy, a rate limiter written from a Reddit thread, then a restricted account and a rewrite.

The reason it is hard is not the API surface. It is that safety on LinkedIn is a hundred small defaults, each of which looks optional until the day it is not: one identity per session, one action at a time, a warm-up with no cliff in it, a country-matched residential IP that nothing else shares, a pending-invitation ceiling, a withdrawal sweep, a calendar day that belongs to the user and not to the server.

Your agent decides who and why. SDR Pilot decides whether, when and how fast. That line is the whole product, and it is the line every raw LinkedIn API refuses to draw, because drawing it means saying no to the caller.

• You keep the ICP definition, the research, the signal detection and the copy strategy.
• You keep your orchestration: Claude Code, Cursor, n8n, Clay, whatever the stack is this month.
• SDR Pilot keeps the LinkedIn session, the identity, the IP, the queue, the caps, the warm-up and the active hours.
• SDR Pilot also keeps the conversation: when a lead replies, it answers from your playbook rather than handing you a webhook and a problem.

Over MCP, in a client you already use: Claude Code, Claude Desktop, Cursor or n8n. You ask for the work in the terms you think in, twenty founders in Berlin who posted about churn this week, and you get back what actually happened, including the part where fourteen passed your ICP and six requests were left in today's budget.

The surface mirrors the app: search people, add and research leads, send a request into the day's queue, read the inbox, reply or hand a thread over, post and pull the engagers in as leads. Nothing an agent can ask for is something a person could not do in the product.

Early access, said plainly: the MCP server and API keys are not shipped. There is no package to install, no endpoint and no tool list to copy today. Ask for early access in the DM and you go on the list.

An external agent proposes, SDR Pilot disposes. The caps are not parameters. 20 connection requests a day per sender with a ceiling of 25, 100 messages with a ceiling of 250, 250 profile reads, 30 searches. A new sender starts at 5 requests a day and reaches 20 on day 16. One LinkedIn action at a time. One browser identity per sender on one dedicated residential IP in the account's country. Your active hours, your calendar day.

Ask for two hundred and you get twenty today, twenty tomorrow, and a straight answer about the rest. If that is a dealbreaker, this is the wrong tool and a raw LinkedIn API is the right one. It is also the reason this exists.

At the end of it. Enrichment, intent and scoring happen in your stack, in whatever order is cheapest, and the survivors arrive here. SDR Pilot then does its own profile read and its own ICP score before sending, which is a second gate rather than a duplicate: yours decides who is worth the budget, ours decides whether this specific profile, read today, is worth one of the day's twenty.

Both gates are yours to tune. The ICP lives in the app and the playbook is a document you edit, so the judgement is not buried in a prompt you cannot see.

• No shipped MCP server or API keys yet. Early access, by DM.
• No webhooks, no CRM sync and no Zapier.
• No email or WhatsApp. SDR Pilot is LinkedIn only.
• No way to raise the caps past the published ceilings, for you or for your agent.
• No free tier and no checkout. Access is allow-listed.