Skip to main content
Glama

lemlist_create_lead

Create a lead in a campaign.

Several leads: lemlist_push_rows reads them from a datastore table instead.

All lead fields are optional (lemlist accepts phone/LinkedIn-only leads), but you'll usually pass at least email or linkedin_url. custom_variables merges extra key-value pairs into the lead, used for campaign personalization (e.g. {{variableName}} in a template). Each value goes as text (a number or boolean written out, a list joined); an object or null is refused (lemlist_custom_variable_value), and so is a key that is a lead field such as email or firstName (lemlist_custom_variable_collision) — pass it through its argument.

Enrichment flags (all default False, each may cost lemlist credits): deduplicate skips the insert if the email already exists in another campaign, linkedin_enrichment runs LinkedIn enrichment, find_email/verify_email find or verify the email, find_phone finds a phone number.

campaign_id is lemlist's campaign id as it returns it, WITH its cam_ prefix (cam_A1B2C3…) — an id without it is refused before any call.

Returns the created lead, including _id — pass it to lemlist_launch_lead/lemlist_add_lead_variables. A response without a lead _id is a named refusal (lemlist_lead_not_created), never a success. review_state is always "unknown": lemlist's answer does not say whether the lead is held for review or already in sequence (its isPaused does not tell them apart, so it is removed). To know if it will send, read lemlist_campaign(op="reports"): reviewedCount or inSequenceLeadCount rising with the add means it goes out; only totalCount rising means it is held for review until lemlist_launch_lead. A 404 « Campaign not found » is a named refusal (lemlist_campaign_not_found): the campaign is not reachable by the key in use for leads, even if its reports are.

A lead lemlist refuses as a DUPLICATE is not an error: the call returns {created: false, reason, message, campaign_id, lead} with reason already_in_other_campaign or already_in_campaign — nothing was created; count the contact as already taken and move on.

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": {
      "campaign_id": "<campaign_id>"
    },
    "name": "lemlist_create_lead"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
emailNo
phoneNo
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
_run_idNoOBLIGATOIRE à 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.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
timezoneNo
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
job_titleNo
last_nameNo
find_emailNo
find_phoneNo
first_nameNo
icebreakerNo
campaign_idYes
deduplicateNo
company_nameNo
linkedin_urlNo
verify_emailNo
contact_ownerNo
company_domainNo
custom_variablesNo
linkedin_enrichmentNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/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: it discloses credit cost per enrichment flag, the `cam_` prefix precondition enforced before any call, two named custom-variable refusals, a 404 refusal name, and the crucial fact that a duplicate is a non-error success-shaped response (`created: false`). It even explains the review_state limitation and how to detect review via `lemlist_campaign(op="reports")` counters.

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?

Front-loaded with the one-line purpose and the sibling disambiguation, then organized into paragraphs by topic (fields, enrichment, campaign_id, returns, duplicates). It is long but nearly every sentence adds operational information; a few clauses, such as the parenthetical about `isPaused`, could be tightened.

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

Completeness5/5

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

For a 23-param mutation tool with no annotations and no output schema, the description covers what an agent needs to call it correctly and interpret the result: success shape (`_id`), named failure modes, duplicate semantics, cost implications, and the follow-up tools (`lemlist_launch_lead`, `lemlist_add_lead_variables`). Nothing material is left to inference.

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 22% across 23 params, so the description must compensate; it does for the hard ones — `campaign_id` format with `cam_` prefix, `custom_variables` value coercion rules (text only, objects/null refused, key collisions with lead fields), and each enrichment flag's effect. The plain lead fields (timezone, icebreaker, contact_owner, company_domain) are left to their self-evident names, which is a minor residual gap.

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?

Opens with a specific verb+resource ("Create a lead in a campaign") and immediately names the sibling that handles the bulk case ("lemlist_push_rows reads them from a datastore table instead"). An agent can distinguish the single-lead path from the bulk path without opening either schema.

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?

Explicitly routes single-lead creation here and multi-lead creation to lemlist_push_rows, states the minimum viable payload ("you'll usually pass at least `email` or `linkedin_url`"), and warns which enrichment flags consume credits. It also tells the agent what to do on a duplicate ("count the contact as already taken and move on") rather than retrying.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources