.png)
Your agent needs to run outbound in Lemlist: audit campaigns, source leads, rewrite a failing sequence step, pause a campaign that is burning sender reputation. Lemlist ships a hosted MCP server at app.lemlist.com/mcp and a REST API at api.lemlist.com/api. Most MCP-versus-API comparisons resolve into "MCP is easier, the API is more powerful, and the API has better auth." For Lemlist, the last part is backwards. Here is the actual decision framework.
These are two different products from the same vendor, aimed at two different consumers. One was designed for a chat client with a human watching. The other was designed for a backend integration that runs unattended.
The official Lemlist MCP server is hosted by Lemlist at https://app.lemlist.com/mcp and speaks JSON-RPC 2.0 over HTTP. Authentication has two modes: browser-based OAuth, where the client handles discovery, dynamic client registration, consent, PKCE token exchange, and refresh; or a static API key sent in the X-API-Key header.
On the OAuth path, the consent screen asks the user to select a team, and Lemlist documents an access token lifetime of about one hour with a refresh token lasting about 30 days. Lemlist does not document per-tool scope selection on that grant.
The Lemlist REST API lives at https://api.lemlist.com/api and covers the full platform: campaigns, sequences, leads, contacts, companies, schedules, tasks, inbox, enrichment, lemwarm, unsubscribes, webhooks, and the People Database.
Authentication is HTTP Basic, and the details matter: the username is always empty, the password is your API key, and you Base64 encode the string :YourApiKey including the leading colon. There are two API versions, and v1 is deprecated. Some endpoints still default to v1, so you pass version=v2 as a query parameter on those routes.
Four dimensions decide this for an agent: what the tools can reach, whether the tool surface is actually a boundary, what credential model each path forces on you, and what breaks in production.
The MCP server covers the operator loop well. The gaps are concentrated in scheduling, task management, bulk data movement, and the lead state machine.
The gaps are not random. Lemlist built the MCP server for a human in a chat window, so it composes multi-step operations and omits the machinery a backend integration needs.
lemlistmcp_validate_campaign_readiness checks step content, sender configuration, DNS health, and daily limits in one call. lemlistmcp_check_domain_health returns a 0 to 100 score with per-check status and the DNS records needed to fix failures. lemlistmcp_preview_sequence_update is a mandatory read-only diff before lemlistmcp_update_sequence_step. There are also memory tools that persist user and team context across conversations, and lemlistmcp_load_skill, which pulls in domain guidance on demand.
None of that composition exists in the REST API. Equally, none of the API's scheduling, export, or lead-lifecycle control exists in the MCP tool list.
There is one exception, and it is the single most important thing to understand before you hand this server to an agent.
lemlistmcp_call_api takes an endpoint path, an HTTP method, and an optional body, and makes a direct call to the Lemlist API. It is gated only by requiring lemlistmcp_load_skill('api-reference') to have run earlier in the session. That gate is a session precondition, not an authorization check.
The consequence is structural. If you expose the full MCP server to an agent, every capability in the "No" column above becomes reachable anyway, and every allowlist you thought you had at the tool level stops meaning anything. Tool-level least privilege on this connector only holds if lemlistmcp_call_api is excluded from the surface.
Here is where Lemlist diverges from Notion, Slack, and Salesforce. On those platforms the MCP server is the auth-constrained path and the REST API is the flexible one. Lemlist is the reverse.
The MCP server accepts OAuth with dynamic client registration and PKCE, and it accepts a static API key. The REST API's documented method is Basic auth with an API key, full stop. Lemlist's CLI offers an OAuth login for profile management, but the API reference documents Basic auth as the way to authenticate a request.
That means the MCP path is the only Lemlist path where a user grants your agent access through a consent flow instead of pasting a secret into your product. For a B2B product onboarding customers, that difference is the onboarding funnel.
The multiple accounts guide states the constraint plainly: a Lemlist credential resolves to exactly one account, there is no account parameter, and there is no separate login step. The credential is the account selector.
Both paths inherit this. On MCP with OAuth, you add one connection per account and the consent screen binds it to a team. On the API, you hold one key per account and switch keys to switch accounts. Forty customer accounts means forty credentials either way.
One more identity detail deserves attention: lemlistmcp_send_message requires an explicit sendUserId in usr_xxx format, and lemlistmcp_set_campaign_senders takes an arbitrary array of team member IDs. Sender identity on those tools is a model-supplied parameter, not something the transport derives from who authorized the grant.
Lemlist maintains the MCP server, its tool schemas, and the composite logic behind tools like readiness validation. Lemlist explicitly notes that the tool set evolves and tells clients to re-enumerate rather than hardcode. That is a managed contract without a version pin.
The REST API gives you the opposite tradeoff. You pin version=v2 and control your own migration, but you own request construction, pagination, retries, and error handling. Rate limits are 20 requests per 2 seconds per API key on all routes, with Retry-After, X-RateLimit-Remaining, and X-RateLimit-Reset on every response. Lemlist does not document separate limits for MCP.
Both paths leave you with token storage, refresh, revocation detection, and tenant isolation.
Several destructive and expensive Lemlist tools take a userConfirmed or confirmed boolean: deleting a company, deleting a sequence step, disconnecting an email account, starting or archiving a campaign, and reversing an unsubscribe.
Read the flow carefully. The tool description instructs the model to set the flag only after the user says yes. The model sets the flag. Nothing outside the model verifies that a human ever saw the question.
For an interactive assistant with a person watching, that is reasonable. For a background agent, a prompt-level gate on a tool that spends enrichment credits or archives a live campaign is not a control you can put in a security questionnaire. Enforcement has to happen at the tool surface, before the call.
The split follows the two products rather than the two protocols.
Use Lemlist MCP when:
Use the Lemlist API directly when:
Both paths hand you a credential per Lemlist account. Neither hands you a vault, a rotation loop, or a revocation flow.
Your product serves 40 customers, each with their own Lemlist account. On the MCP path that is 40 OAuth grants, each with an access token expiring roughly hourly and a refresh token expiring in about 30 days. On the API path it is 40 API keys, each shown once at generation and never displayed again.
The MCP grant's roughly 30-day refresh window is the one that bites quietly. It does not fail on deploy. It fails on day 31, for one tenant, inside a scheduled run, with no user present to complete a browser consent flow.
Storage, encrypted at rest and namespaced per tenant, so one customer's credential is not reachable from another's execution path. Proactive refresh driven by expiry rather than by catching a 401 across concurrent agent threads. Revocation detection, because a Lemlist user regenerating an API key or revoking a consent grant does not notify your system.
Scalekit's Lemlist MCP connector handles the OAuth flow, per-tenant token storage, and refresh, so the MCP versus API decision does not change your auth infrastructure.
Scalekit's catalog currently lists one Lemlist connector, lemlistmcp, with OAuth 2.1 and dynamic client registration as the authorization type. If you need the REST-only surface, the bring your own connector path covers it with the same connected-account model, so both surfaces sit behind one credential layer.
Create the connection once in AgentKit > Connections. The connection_name you pass in code must match the connection name configured in the Scalekit dashboard exactly; this is the most common integration error.
Before any tools reach the model, retrieve the tools this user's connected account is authorized to call. This is not exploration of an unknown surface; it is a scoped, deterministic list derived from one user's grant.
The Lemlist MCP connector catalogues 62 tools. At Scalekit's working estimate of roughly 200 tokens per tool definition, that is around 12,400 tokens consumed before the agent does any work, on every run. A campaign audit agent needs five of them.
Surface reduction is the lever here, and it is an accuracy lever before it is a cost lever. A model choosing among 62 outbound tools, several of which spend enrichment credits and several of which mutate live campaigns, will pick wrong more often than a model choosing among five read-and-preview tools. Note that lemlistmcp_call_api is absent from the list below by design.
Scalekit injects the user's Lemlist credential server-side on each call. The token never enters the agent runtime and never appears in LLM context.
A real outbound agent is not Lemlist-only. It reads Lemlist campaign stats, then posts a digest to Slack. Virtual MCP servers let you declare that combined surface once, as a single scoped endpoint, instead of wiring two MCP servers and two credential paths per user.
Two objects drive the model. The server is created once per agent role and returns a static mcp_server_url. The session token is minted before each run and binds that static endpoint to one specific user's connected accounts.
Before each run, confirm the user's connections are still active, then mint a short-lived token. This is where a revoked Lemlist grant or an expired refresh token surfaces as an actionable auth link instead of a mid-run failure.
One server definition serves every tenant. The endpoint is static; the identity is not.
Enforcement without evidence does not survive a security review. Every execute_tool call returns an execution_id, and Scalekit's auth logs record authentication and token events across users, agents, and machine clients, filterable by user, organization, method, and status, and streamable to your SIEM or warehouse.
For an outbound tool this matters more than usual. When a campaign gets archived or 500 leads get enriched at cost, "which agent run, acting for which user, under which connected account, called which tool" is the question you need answered in minutes, not the three weeks it takes to reconstruct from application logs. This is exactly the observability challenge production agent teams face.
If your Lemlist agent is interactive and the user is present, build on the MCP server. The composite tools save you real REST assembly work, and OAuth with dynamic client registration is the only Lemlist path that gives you a proper delegated grant instead of a collected secret.
If your agent runs on a schedule, drives lead state transitions, or exports data, build against the REST API. Those capabilities have no MCP tools, and a pinned version=v2 contract beats composite convenience in a deterministic pipeline.
Most production outbound agents end up on both. What does not change is the credential layer: one credential per Lemlist account, stored, refreshed, and revoked outside your agent runtime, behind a scoped tool surface with an audit trail attached to a real user.
Bring your architecture questions to the people solving them right now. Join the Scalekit Slack community to compare notes with other agent developers, or talk to us if you want help wiring a multi-tenant Lemlist agent this week.
Browse the Scalekit Lemlist MCP connector and the connector documentation.
