Tulina

lemlist_campaign

Manage campaigns: create, configure, pause, duplicate, validate, report, export. oto_guide op=read slug="lemlist-playbook": build order, where each id comes from, and the doc↔API gaps.

Nothing here sends by itself — but a created or duplicated campaign is born RUNNING (its status reads "draft"): op="pause" is the switch. Putting messages on the wire is lemlist_campaign_start (hidden by default — enable it with oto_enable_tool lemlist_campaign_start).

Args by op:

create: name (required), optional timezone (IANA, drives the auto-created schedule; server default Europe/Paris). Returns the campaign with sequenceId and scheduleIds — the two ids lemlist_sequence and lemlist_schedule need. settings is REFUSED here (the endpoint takes name + timezone only) — chain update on the returned id rather than believe a setting landed. ⚠️ The campaign is created in state RUNNING, not draft (its status reads "draft" only because it has no step and no lead yet). It sends nothing while the review gate holds, but chain op="pause" if you want to build it with the switch off.
update: campaign_id + name, sender_user_ids (usr_…, the senders) and/or settings (raw PATCH body: stopOnEmailReplied, stopOnMeetingBooked, stopOnLinkClicked, disableTrackOpen, disableTrackClick, disableTrackReply, tracking, onReplied, aiFeatures…). Only the keys sent change.
pause: campaign_id. THE off switch — a campaign created here is already running. Stops it advancing; already-scheduled leads are NOT recalled. Errors if the campaign is not running.
duplicate: campaign_id + optional name. Copies sequence, steps, schedules and AI templates into a new campaign (CRM settings excluded). ⚠️ Like create, the copy runs (state running in reports) although its status reads "draft": chain op="pause" to hold it.
statutes: campaign_id. The validation the lemlist UI runs — read it BEFORE starting: level 3 blocks the launch (no sender, broken DNS), 2 warns (daily limit, missing schedule), 1 informs.
reports: campaign_ids. One row per campaign in operator vocabulary (emailsSent, emailsOpened, emailsReplied, senderNames, state) — the shape for comparing campaigns.
batch_stats: campaign_ids (≤ 100) + optional start_date/end_date (defaults to the whole life), channels (email/linkedin/others), send_user (usr_…|sender@email), ab_selected (A/B). Same counters as lemlist_get_campaign_stats, in one call.
export_start: campaign_id. Opens an ASYNCHRONOUS stats export and returns its id; poll export_status (campaign_id + export_id), or ask to be notified with export_email (+ email).
export_leads: campaign_id + optional state (defaults to all; lemlist's own default filters EVERYTHING out and returns an empty list that reads as "no leads"), format (csv, the API default, or json). Returns the leads directly — the synchronous cousin of the export above.

autoReview/autoReviewConditions are not settable here: they make every added lead send immediately, which would turn lemlist_create_lead into a send path. They live in lemlist_campaign_auto_review, hidden by default — a switch that arms sending should take a deliberate gesture, not ride along in a settings dict.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "op": "<op>"
    },
    "name": "lemlist_campaign"
  }
}

Input Schema

Name	Required	Description
`op`	Yes
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`full`	No
`name`	No
`email`	No
`state`	No
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`format`	No
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`channels`	No
`end_date`	No
`settings`	No
`timezone`	No
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`export_id`	No
`send_user`	No
`start_date`	No
`ab_selected`	No
`campaign_id`	No
`campaign_ids`	No
`sender_user_ids`	No

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so unusually well: it discloses that a created or duplicated campaign is born RUNNING while its status misleadingly reads 'draft', that 'pause' does not recall already-scheduled leads and errors if the campaign is not running, that 'settings' is REFUSED on create, and that autoReview is deliberately excluded because it would turn lead creation into a send path. These are exactly the non-obvious behavioral facts an agent needs before mutating state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The most consequential fact (campaigns are born running, pause is the switch) is front-loaded, and the per-op bullet structure with inline ⚠️ markers makes a long description navigable. It is verbose in places — the closing autoReview paragraph argues policy rather than stating a fact — but for an 11-op, 22-param tool the length is mostly earned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations and no output schema, so the description must supply both safety and return context; it does return context for create (sequenceId, scheduleIds), reports (operator vocabulary) and the async export flow, and covers the async polling path. Remaining gaps are minor: it never explains 'full' and doesn't describe what pause/update/statutes return.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 23%, so the description has to compensate, and it largely does: it gives args by op, including the raw PATCH key list for 'settings', the IANA/default note for 'timezone', the ≤100 cap on 'campaign_ids', the usr_…|sender@email form of 'send_user', and the trap that lemlist's own default 'state' filters everything out. It leaves the 'full' boolean and the return shape of export_status/export_email only partly specified, so not a full 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb set and resource ('Manage campaigns: create, configure, pause, duplicate, validate, report, export') and each op is then named. It actively distinguishes itself from siblings by naming lemlist_campaign_start, lemlist_sequence, lemlist_schedule, lemlist_create_lead and lemlist_get_campaign_stats, so an agent can route without opening other schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is spelled out per op with explicit when/when-not: read 'statutes' BEFORE starting, use 'batch_stats' instead of multiple lemlist_get_campaign_stats calls, use 'export_leads' for the synchronous cousin of the async export. It also names the exclusion (nothing here sends by itself; sending lives in lemlist_campaign_start, which is hidden by default) and the ordering constraint (chain 'update' after 'create').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Tulina tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?